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Networkshop 4 was held at the University of York on 19-20 April 1979. The 
workshop was organised jointly by the University of York Department of 
Computer Science and the Network Unit of the Computer Board and Research 


Councils (now the Joint Network Team). 


This workshop had a similar theme to the previous three workshops, with 
perhaps a greater emphasis on testing and similar practical activities 


reflecting the approach of the PSS starting date. 


The next workshop in the series will be held at the University of Kent in 


September 1979. 
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REPORT FROM THE NETWORK UNIT 


Progress on Standards 


The Department of Industry's Data Communication Protocols Unit (DCPU) is now 
firmly established and the close contacts already established with the Network 


Unit will continue with the Joint Network Team. 


The Post Office has published the technical guide for Levels 1 and 2 of X25 
as they are to be implemented on PSS. Level 3 is expected at the end of May. 


PSS Study Group 3 has produced a draft version of the Transport Service to be 


discussed in detail later in these proceedings. 


The specification of the triple-X terminal protocols (X3, X28 and X29) excludes 
the existence of a Transport Service. A sub-group of PSS Study Group 3 (under 
Peter Higginson at UCL) is studying the question of achieving compatibility 


between triple-X and the Transport Service. 


An active File Transfer Protocol Implementors Group meets regularly under 


Peter Linington's chairmanship. 


The Protocols Unit has brought people together to start work on a Job Transfer 


Protocol. Further information appears elsewhere in these proceedings. 


The seven-layer model of a network architecture, which has been discussed 
at length for about a year in BSI and ISO, is rapidly being discarded. 
Official agreement on protocols within the standards bodies during the next 


two years seems unlikely. 


CCITT, the world union of telephone administrations, has now begun to take an 
energetic interest in high-level protocols. Since this organisation is less 
encumbered by external pressures than ISO, there is some prospect that they 
might reach more speedy agreement. It is to be hoped that the important 
groundwork already covered by ISO will be input into the CCITT deliberations. 


The urgency of our requirements means that our main aim must be to secure the 
definition of those protocols which we need for our own work. Very close 


collaboration must be maintained with the Protocols Unit and an attentive 


eye must be kept on the BSI, ISO and CCITT activities. In this way, we can 
hope to retain the possibility that our protocols can undergo a smooth 
evolution towards the agreed standards when these emerge. Moreover, the 
definition of working protocols can be fed to the standards bodies thereby 


strongly influencing their work. 


Machine Range Activities 


Several projects are in progress under the auspices of the Joint Network Team 
to provide networking facilities for various machine ranges and operating 


systems. 


(a) DECsystem 10 


Ian Service's group at York University is working on the development of 
a gateway between DECnet and X25. Initially, their DECsystem 10 will be 
connected to the SRC network using SRC's version of X25. A later stage 


of the project will be to connect to PSS. 


CAP Ltd have been commissioned to provide a functional specification for 
the File Transfer Protocol on the DECsystem 10. This is an essential 
step prior to any detailed design and implementation that might be 


undertaken. 


(b) ICL 1900 


A feasibility study on networking facilities for ICL 1900's is being 
undertaken by DATASKIL. The scope is restricted to machines which run 
GEORGE 3 (including ICL 2900's under DME). The investigation will take 
into account the various networking projects on 1900's (especially 


MIDNET and GANNET) as well as the multitude of different front-ends. 


(c) ICL 2900 


The joint universities/ICL Networking Task Force has been dormant 
for some time. Until ICL respond formally to the Computer Board's 
letter of April 1978, there seems little point in reconvening. A 
positive reply indicating ICL's commitment to "Open System Interconnection" 


is believed to be imminent. 


(d) PDP-11 


A group of people interested in PDP-11's and networks has been convened. 
A proposal by York University Computer Science Department to provide X25, 
the Transport Service and FTP under UNIX has been accepted. Similar 
projects for other operating systems, especially RSX-11I-M, are urgently 


needed. 


Paul Kummer at Daresbury Laboratory is chairman of the informal group 


and prospective participants should contact hin. 


(e) Manufacturers 


Several manufacturers have given varying degrees of commitment to 
support the standards we are asking for. Among these are GEC, PRIME 


and Honeywell (for Multics). 


PSS 


The Post Office has asked the Joint Network Team to collect the names of 
centres wishing to establish early packet-mode connections to PSS. So far 


the following have expressed such intentions:- 
Centre Date 


York 


) Opening Date of PSS 
Essex ) 

) 

) 


Avon 
NUMAC 
Cambridge ) 
SWURCC ) 
Birmingham) 
Nottingham) 


Leeds Mid-1980 
UMRCC Late 1980 
ULCC Late 1980 


The Computer Board is to be asked to cover the Post Office's installation 
costs at each of the approved sites as well as the usage charges for an 


initial period of experimentation with the new service. 


Work Required 


Figure | illustrates an idealised hierarchy of communications. Among the 
projects which will have to be undertaken on local area communications 


networks are:- 


(a) the further development and perfecting of components based on the 
various principles already proposed (rings, Ethers, central switches). 
This must then lead to the availability of such products from manufacturers 


as catalogue items; 


(b) the interconnection on the same campus of several local networks (which 


might be based on different principles); 


(c) the development of gateways from local area networks to PSS or to another 


site; 


(d) facilities for measuring and controlling access from a given site to 


PSS and to remote computing facilities. 


Figure ] also implies several projects for attaching equipment to networks, 
implementing protocols and providing commonly required components. These 


include:- 


(a) packages for attaching mainframes and midis to PSS with support for 


high-level protocols; 

(b) packages for attaching computers and micros to local networks; 

(c) the provision of servers for local nets to allow the sharing of 
expensive facilities such as line printers, plotters, file storage 


and magnetic tape drives; 


(d) terminal concentrators, PAD's and multi-hosting RJE stations for local 


networks and PSS; 

(e) network status and information services; 

(f) mailbox facilities for human communications; 

(g) spooling systems so that files may be stored temporarily and delivered 
to their ultimate destination at a later stage (this may be needed for 


example when a machine designated as a destination is temporarily busy 


or broken); 


(h) methods for dealing with existing RJE stations which use proprietary 


protocols and are either hardwired or not worth reprogramming. 


The Joint Network Team 


It is obviously too early to give details of the Joint Network Team's future 


programme. However, the main headings are: 


(a) Communications Facilities 


The JNT will act as the focal point for liaison between the university/ 
Research Council community and the Post Office on the use of Post Office 
services including PSS. The JNT will also be involved in identifying 
suppliers of high performance switches for use in private networks where 


appropriate. 


The growing importance of local area networks underlines the urgency 
for standard components to be available as off-the-shelf products from 
manufacturers. Several technologies (ring, Ether, centralised switch) 
are currently under investigation. The JNT will attempt to see that 
such projects reach rapid fruition. Evidence can then be collected for 
subsequent recommendations on what should be the standards for the 


community. 


The JNT will also coordinate development projects aimed at the exploitation 
of basic transmission and switching facilities. Examples of such projects 


are given earlier in this report. 


(b) Standard Protocols 


The JNT will participate in national and international activities on the 
definition of protocols required by the community. Where provisional 
standards are required, the team will hold the definitions agreed within 


the community. 


Several projects are already underway on packages for implementing 
protocols for machine ranges and operating systems and there will be 
more of these in the future. Close contacts will be maintained with 
manufacturers in attempts to ensure that, in the longer term, standard 


networking facilities are an integral feature of manufacturers’ products. 
& gS Pp 


(c) Planning 


The JNT will participate with universities and Research Council centres 
in the formulation of networking plans. The aim will be to ensure that, 
wherever possible, schemes are put forward which offer integrated 


communications arrangements to serve the needs of all the funding bodies. 


(d) Testing and Validation 


The complex nature of data communications and networking technology 
suggests the need for a centre of expertise to assist individual centres 
in implementing network connections and protocols. The possibility of 


this being undertaken by the JNT will receive consideration. 


There is clearly no shortage of potential development projects. The JNT's 
main concern will be to reduce the risk of duplication and to make certain 
that what is developed has the widest possible applicability in the community. 
This implies the JNT's involvement in technical specifications, the monitoring 
of projects during execution, the negotiation of satisfactory maintenance 


arrangements and insistence on adequate documentation. 


Dr R A Rosner 


Joint Network Team 


16 May 1979 
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REPORT OF THE NATIONAL EXPORTING CENTRES GROUP 
APRIL 1979 


Introduction 


In March 1978, the Network Unit invited representatives from ULCC, UMRCC, 
NUMAC, Cambridge, Rutherford and Daresbury to an informal meeting to discuss 


communications questions of common interest. 


Since the remote users form a high proportion of their total user communities, 
it was thought likely that all these centres will eventually make use of 
connections to PSS. The problems of effecting such connections and the 

need to have a focus for negotiations with the Post Office were therefore 


among the items to be covered. 


The: large size and wide geographical dispersion of these centres’ dependent 
user communities mean that decisions which have to be taken on such matters 
as addressing or protocols could have an influence on what happens in many 

other places. The meeting was seen as offering the opportunity to discuss 

protocols with a view to ensuring maximum compatibility of implementations 

among all the centres. This would in turn help to propagate standard 


implementations throughout the rest of the community. 


The presence of representatives from centres funded both by the Computer Board 
as well as by the SRC meant that the basis for future collaboration could be 
laid and initial steps taken towards greater integration of communications 


arrangements among the funding bodies. 
The main conclusion of the initial meeting was that there was sufficient 
common ground to warrant regular meetings and these have since taken place 


at 2-monthly intervals. 


Aims 





The aims of the group are:- 


(a) to exchange information on arrangements for connecting each national 


centre to PO PSS so as to ensure compatibility; 


(b) to provide a focus for discussion with the Post Office on national centres! 


communications needs and problems; 


(c) to collaborate on the understanding and interpretation of CCITT, ISO 
and BSI standards and proposals, and the achieving of compatible 


implementations; 
(d) to consider the need for the adoption of interim standards; 


(e) to ensure full exchange of information, plans and proposals within the 


university and Research Council community. 


Some Areas Covered 


All the centres have given regular progress reports on their communications 


and front-ending activities and this has led to discussion of common problems. 


X25 has been given much attention from an implementor's point of view. Al] 
parties agree on the need for conformity with the PSS version. In the absence 
of the PO's technical guide,. the best that can be done is to ensure that all 
the centres adopt the same version with simultaneous conversion to PSS being 


effected at a later date if necessary. 


The progress being made on the definition of a Transport Service by the 
Post Office's Study Group 3 is being noted. Detailed information will be 


presented at the York Networkshop. 


The need for a unified addressing scheme has been recognised and a suggested 
scheme, drafted in consultation with many other groups, is currently under 
consideration. This topic will be fully discussed at the Networkshop. The 
Study Group 3 Transport Service proposal includes guidelines for an addressing 
structure. This will in general require more bytes than are available in 

the Call User Data Field of the standard X25 Call Request Packet. However, 
the Fast Select Facility, which will be implemented on PSS, allows for 

128 bytes of Call User Data. It is, therefore, recommended that all sites 
connecting to PSS subscribe to the Fast Select Facility to simplify the 


implementation of the SG3 addressing scheme. 


The UK Network Independent File Transfer Protocol will ultimately be supported 


at all centres. The urgent need for a Job Transfer Protocol has been identified . 


and the Protocols Unit has now stimulated new activity in this area. Once 
a satisfactory definition has emerged, centres will give serious consideration 
to implementing it as an alternative to and eventual replacement for the 


current proprietary protocols. 


All sites connecting equipment to networks will require data communications 
test equipment. A survey of available products has been conducted and the 

results will be presented at the Networkshop. It has been suggested that a 
pool of recommended devices and a suite of useful software for them be kept 


centrally and loaned to any sites wishing to use them. 


Timescales for PSS Connections 


The expected dates by which centres will be capable of offering an initial 


service to users via PSS are 


UMRCC Late 1980 
ULCC Late 1980 
Cambridge Opening date of PSS 
NUMAC Opening date of PSS 
Rutherford Opening date of PSS 
Daresbury Opening date of PSS. 


Relations with the rest of the Community 


It 1s not intended that the group should be yet another committee defining 
protocol standards. A member of the Department of Industry's Data Communication 
Protocols Unit participates in the group's meetings to clarify problem areas. 
The emphasis 1s very much on the pace and compatibility of implementation 

so that the major centres are aware of each other's work and can take steps 

to ensure the capability to interwork at all stages of their separate 
programmes. Where decisions are required which could have repercussions in 
other places, prior consultation will be organised by the Joint Network Team 

and regular reports of the topics discussed will be circulated for information 


and comment. 


Roland Rosner 
Joint Network Team 


10 April 1979 
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The Data Communications Protocols Unit 


Keith Bartlett 
Protocols Unit 
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Tne Data Communication Protocols Jnit 


Tne oroblems of ‘user’ standards in networks such as Transport 
Service and the higher level protocols nave been recognised by 
tne formation of national and international standards committees 
which have, in turn, formed a number of working grcups. The 
effectiveness of the committees and working groups is deosendent 
upon the expertise of the membersnip which is drawn from users, 
manufacturers and research institutes with particular interest 
in tne subject matter. This membership muSt be backed uo by a 
comprehensive orogramme of development and investigation. The 
raoid progress in. the use of networks which nas taken place in 
the tast twO years means that the identification of tne 
necessary standards and thefr relationship to eacn otner is not 
yet complete. 


Research and dcevelopment on these standards iS carried out in 
the °-ost uffice and in eStablishments funded poy the Science 
Reasearch Council, the Computer Board for Universities and the 
Department of Industry but this work has not been co-ordinated 
and many subjects have been left uncovered. 


Tnis nas led to the formation cf a Data Communication Protocols 
Jnit (OCPU) at the National Physical Laboratory with a Steering 
Cummittee chaired by Morley Sage of Southampton University. 
Roland Rosner is another member of tnat committee. 


Tne Unit wiltl work in conjunction with BSI committee DPS/20 and 
tne chairman, Frank Taylor, is another member of the Steering 
Committee. 


Tne ourpose of the Unit its to coordinate and encourags tre 
necessary development work on the identification and generation 
of protocols and standards for general purpose data 
communication networkse At pFesent, the JUnit has @ Aredicted 
lifetime of only two years because it iS tmportant that tnese 
developments be carried out early enough to allow imnediate, 
sffective use to be made of switcned networks as they become 
available in the UK and enanle the UX to make effective 
contributions to international standards. 


Tne Unit will also act as a clearing house through which the 
oresent and anticipated needs of the users are prought to the 
attention of those developing the Standards. 


Tne Unit will encourage and monitor appropriate development work 
on higher level protocols and help to bring this work to the 
level of naticnal and international standardse The full 
reauirements and implications of standards in computing and 


communications are not yet clear and part of the work will oe an 
assessment of how these standards muSt be supported and 
nmaintainede The Unit will provide information on the existence 
and state of communication protocol use and development tn the 
Jnited Kingdom. It will maintain a reference lJiorary of 
relevant literature and specifications and make this available 


as required. 


Tne Unit held a small workshop on the Transport service 2roblem 
just bobefore Christmase The raised some points for further 
consiageration by the Working Group on Transport Service from 
Post Uffice Study Group 3. Since then, this yFoup nas completed 
a draft proposal for a Transport Service interface and an 
interpretation cf this on an X25 network. This docunent is 

be ing circulated through the Unit. 


Another mseting was held at ULCC to consider now the Remote Job 
oroblem might be tackled. This resulted in a very snall working 
group convened by Andrew Chandler of CADC. Additional members 
for tnis group would be welcome. Tne first target will orobably 
be to define a job transfer protocol, based upon FTP, for use 
between intelligent hosts. The effort available for this work 
Nay not be sufficient and tne DCPU will try to contract tne 
services Of a suitable consultant. 


The Unit is tn Contact with Frencn and German ofganisations 
interested in the early availabl.ity of suitable protocols. 


Keith sartilett 
OCPU 


1zZ 
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X25 Frame level interface for packets (FLIP) 


Jon Prout 
Post Office 
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X25 FRAME LEVEL INTERFACE FORK PACKETS (FLIP) 


CUNTENTS 

1 INTRODUCTION 

2 COMMANDS 

3 PX COMMAND 

F TR COMMAND (FRAME TRACE) 

5 FX COMMAND 

6 USE OF THE FLIP PROGRAM 

THY/NP4.1.24/NRH Issue 3 


April 1979 


12 


4 U:TRODUCTIO\N 

nis process allows access to the X25 frame level interface. Keyboard commands alici, 
botn level 2 frames and level 3 packets to be transmitted and monitored. The use of 
FLIP requires a special set-up procedure. The full 
user interface has not yet been defined = please note the warnings in Section 6. 


Cc COMMANDS 


The following main commands may be entered:- 


Ei, To terminate the FLIP process. 

PX To cause FLIP to transmit a level 3 packet (see Section 3). 

IR To display the last few frames received or transmitted (see Section +). 
OFF To stop the display of frames (see Section 4). 

FX To cause FLIP to transmit a level 2 frame (see Section 5). 


3 THE PX COMMAND 


Tnis command will cause FLIP to pass a packet, of the required format, te level é for 
transmission. Level 2 will handle the transmission automatically (ie sesuence anc ecu). 
ine type of packet sent deperds upon the parameters given below:- 


PACKET TYPE COMMAND 

- (DTE DCz) 
CALL REQUEST PX CALL LOi, CING.£,CED.A,PAC.PpIk,...- 
CALL ACCEPTED PX CAA LCN 
CLEAR REQUEST PX CLR LCN,CAUSE,CODE 
CLEAR CONF PX CLC LCN 
DATA PX D LON,PR,PS,Q,M,DATA 
INTERRUPT PX INT LCN,USER DATA 
INTERRUPT CONF PX INC LON 
RR PX RR LCN,PR 
RNR PX RNR LCON,PR 
REJ PX REJ LCON,PR 
RESET REQUEST PX RST LCON,CAUSE,CODE 
RESET CONF PX RSC LCN 
RESTART PX RES CAUSE,CODE 
RESTART CONF PX REC 
NOTES 
LCN - Logical Channel Number 1-3 Hex digits. 
CING.A - Calling Address O-15 BCD digits. 
CED.A - Called Address O-15 BCD digits. 


FAC-PAIR - Facility pair 3-4 Hex digits. 


CAUSE - Cause byte 1-2 Hex digits. 
CODE - Code byte “1-2 Hex digits. 
PK - P(R) 1 Hex digit. 


PS - P(S) 


w = @ bit to be set ) 


M- M bit to be set ) 


DeTA = IAD 


) @ or M may be omitted. If both present the 
order must be Q, M.- 


Up to (and including) <CR> go into packet- should 
not start with © or M. 


USER DATA = User data byte 1-2 Hex digit. 
Only 1 space (or,) between any field. 
mm THE TR COMMAND (FRAME TRACE) 


Format 


Function 


lhote 


TR or TRI. 

The trace command instructs FLIP to display all frames (all I frames 
for TRI) sent or received by the tester. When in the Trace moa 
other commands may be entered but the display will ‘creak in' i 
it has a frame to show, eg 


~~ 
a 
a 
a | 
a 
- 


Tk 

* * FLIF prompt 

> Rk @ Trace ‘break in! 
S Re 2 

FX SARM Local prompt (no '.'), user eriters next comcone 


The trace may be stopped by the OFF command or by terz=inal 
'break' (Reset). 


The size of the trace queue is limited and works on a ‘wrap 
round' basis. 


When using trace on a slow character terminal some information 
will not be displayed if the sequence exceeds 7 frames. 


4a 


4 frame 1S oniy displayed once, the format is giver below:- 


<A L2 TYPE P/F N(R) K(S) Send frame 
/I TYPE P/F h(E) W(S) Receive frame 

7 I P=P bit set I frames only 
OR SARM F=F bit set 
3 DISC 

Us RR 

CMUX RiiR frames 

Rox! ReJ only 

Rawk I 

= 


Lach I frame is also described in level 3 terms as follows:- 


L3 TYPE GLCN P(R) | P(S) MXXK 


| |! 


Ci First e bytes D packets Secord ¢ bytes 
CLO of packet only c= packet 
CALL 

Cab RR 

RST kivk Packets 

RSC Rew only 

RES D 


Y 


Int 
Lic 
RR 

kuiR 
kuru) 
D 
? 


4 





L434 TYPE unknown 
Ry THE FX CUMMAND 


The command will cause FLIP to transmit a level 2 frame according to the following 
parameters:-=— 


FRAME TYPE COMMAND 
SARM FX SARM 

DISC FX DISC 

UA FX UA 

CMDR FX CMDR 

RiJ FX REJ 

RNR FX RNR 

RR FX RR 

I FX I XXXXXXXX (XX = Hex digits) 
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6 USE OF TH FLIP PRUGRAM 


If a command or parameter cannot be found the signal ?7 is given. lo syntax or: 

range checks are made on PX or FX commands. The level 2 protocol runs automaticalir - 
misuse of the FA command may cause level 2 to ‘lock up' and hencerequire system 
reload. 


Ary 


TESTING AID PHILOSOPHY 
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: Test Commands 
DTE Test . 
or X25 | nd 
DCE Routines | Response/ 
Diagnostic 
1. DTE Development/Debugging 


2. Demarcation Resolution 


3. Permission To Connect (Ap >rovai} 


Ob 


X25 PROTOCOL TESTER ~ TEST CONFIGURATION 
(CONTROL ACCESS) 


Pape fit EXCHANGE 


" PROTOCOL TESTER 


CUSTOMER ACCESS 

DTE 
UNDER 
TEST 





CIRCUIT 


TEST AND 
CONTROL 





| 
| 
| 
— 

RIVER PLATE HOUSE. 
Pa PACKET TERMINAL 7 
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TEST | 


PROCEDURES 
SUPERVISION 


TERMINAL 
HANDLER 





OZ 


2 © & © © 


X25 PROTOCOL TESTER SOFTWARE BREAKDOWN 





MONITOR 
AND 
CONTROL 
CUSTOMER MODEM CONTROL | @) 
FRAMING ETC X25 LEVEL 1 


DATA X25 X25 MODEM 





SOURCE LEVEL 3 LEVEL 2 INTERFACE 

X25 LEVEL 2 | CONTROL | CUSTOMER 
ACCESS 
CIRCUIT 

X25 LEVEL 3 





APPLICATIONS — DATA SOURCE 
AND DATA SINK 


STANDARD SYSTEM INTERFACE 


CONTROL AND TEST 
SOFTWARE 


A IMS  F THE TEST ER 


TO PROVIDE DIE MANUFACTURERS WITH A SELF SERVICE 
DEVELOPMENT AID. 


TO ENCOURAGE A MODULAR APPROACH TO DTE IMPLEMENTATION. 


TO ASSIST IN EVALUATION OF DTE FOR PERMISSION TO 
CONNECT PURPOSES 


TO PROVIDE SUBSEQUENT MAINTENANCE AID. 


OT HER A ID S§ AVAI1LLABLE T QO TRE P.Q 


-_-— SS eS SE eS SES eS | eo i oo i a a eo oe a oe a a at ee ee ee ee ee ee ee ee ee 


da DIAGNOSTIC AIDS AT THE NETWORK MONITORING CENTRE. 
a DATASCOPES. 

Gs TEKELEC TE 92 X25 ANALYSER. 

4. ATLANTIC RESEARCH INTERSHAKE. 
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X25 Networking on the DECsystem-10O 
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The University of York has received support to implement an X25 network 
connection for the DECsystem-10. This DECsystem-lO network will initially 
aim to connect with SRCNET which is already X25 based but will ultimately 
allow connection to PSS. 


The network link will be based on an existing DEC-1O only network facility 
called ANF-10 (Advanced Network Functions also occasionally called DECnet-10), 
and will be implemented as an internetwork link or gateway between ANF-1O 

and the X25 network. This gateway will be implemented on a separate PDP-l1l 
computer which will run all the software to translate between the two 
networks. 
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As few changes as possible are being made to the DECsystem-10, the only 
changes to the monitor being the addition of some tables to store where 
incoming network users come from. All changes should be completely 
transparent to the normal DECSystem-lO user. 


File Transfer: Rick Blake (Essex) 


As a separate exercise CAP have been commissioned to write a functional 
specification of an FTP-B implementation for the DECsystem-loO. 
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PDP-11l Network Users Meetings on 20 December 1978 and 14 March 1979 


Minutes 
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PDP11 NETWORK USERS MEETING 


DARESBURY LABORATORY, 20 DECEMBER 1978 


With the announcement of PSS by the Post Office, it was thought appropriate 
that a meeting should be set up to bring together people concerned with 
connecting PDP11‘s to networks in general and to PSS in particular. The aims 
of the meeting were: 


ir to identify common requirements; 
26 to discuss schemes of general applicability; 
3 to specify the technical details of implementation; 


4. to formulate a collective programme of work aimed at reducing 
duplication of effort and diversity of implementation. 


A fairly representative group of potential network users attended the meeting 
despite the bad weather. A survey of those present showed that there was a 
general intention to connect to networks but very little effort available 

for implementation. The possibility of a centrally provided and maintained 
implementation was discussed and agreed to be worth pursuing. The following 
operating systems were of interest:- 


os Number of sites 
RSX-11-M 9 
RSX-11-D 1 
UNIX 8 
RT~ | 1 2 
RSTS 3 


The meeting agreed that a small working group should be set up to investigate 
the problems and possibilities of a centrally provided implementation. The 
working group was to determine what was required and what was available. This 
could then form the basis of a set of projects or contracts to provide the 
required software. . 


The working group was to produce a report by 16 February 1979 so that it 
could be distributed well before the next full meeting. The working group's 
report 1s attached to this summary and will be discussed at the next meeting 


which will be held at:- University of London Computer Centre, 
20 Guilford Street, 
London WCIN 1DZ 


on 14 March 1979, at 11.30 am. 


Paul Kummer 
12 February 1979 


PDP-11 NETWORKING 


lis Introduction 


The widespread use of PDP-]1's throughout the university and Research Council 
community and the intention of several users to connect their machines to 
networks have stimulated an investigation of methods for providing the 
appropriate facilities. Following a meeting attended by several PDP-11 users 
organised by Daresbury Laboratory in December 1978, an ad hoc group was 
formed to draft a set of networking capabilities, to investigate what work 
had already been done and to suggest means of providing fully engineered 
packages to achieve the required functions. Manpower constraints mean that 

a most desirable objective is to reduce duplication of effort and diversity 

of implementation possibly by having a limited number of well documented 
packages which are held and maintained centrally and distributed to 


installations requiring then. 


Zs Requirements 


Figure | lists the main operating systems of interest to the community and 


figure 2 is an initial set of networking facilities to be provided. 


(a) Communications Hardware 


Several pieces of hardware are available for handling communications 
lines. There are advantages in using standard products supplied by 
Digital but it may be worth investigating the hardware which some 

groups have built themselves. Moreover, Digital's more recent offerings 


also need to be evaluated. 


(b) X25 


The Post Office PSS version of X25 is the definitive standard which 
ought to be followed. This will accept both BSC and HDLC frame 
Structures and both LAP and LAPB classes of HDLC procedure. 


(c) Transport Service 


The PO Study Group 3, in conjunction with the Department of Industry's 
Protocols Unit, is working on the definition of a "thin" Transport 
Service layer. A preliminary document has already been circulated. 


By the summer, a workable version should have been published. 


£0 


(d) Terminal Support 


There is a need to support remote terminals accessing a PDP-11 over a 
network and X29 will thus be required. For terminals attached directly 
to a PDP-11 wishing to access remote facilities over the network, the 


PDP-11 will have to act as a BAD in conformity with X3 and X29. 


(e) File Transfer 


The standard UK File Transfer Protocol is required. 


(£) Job Transfer 


It is likely that work will soon begin on the definition of a basic 
Job Transfer Control Protocol which will use the facilities of FTP 


for the file shipment parts of the Job Transfer sequence. 


(g) Multi-Hosting RJE 


PDP-11's frequently act as-RJE stations and, once a satisfactory network 
job transfer protocol has been defined, there will be growing demands 
for multi-hosting workstations. This 1tem is included for completeness 
though such software would not necessarily be used with any of the 


operating systems mentioned. 


Current Projects 


Work is believed to be in progress on the provision of separate solutions 
for each operating system. Attention has, however, been drawn to the work 
of Colin Bradbury at UCL who has produced a set of modules for X25 
designed to be coupled to any operating system. Figure 3 illustrates the 
Structure and shows that only the interface module between COMSYS and the 
operating system requires construction in each case. This approach has the 
attraction of providing common implementations of the same function under 
different operating systems with the important attendant advantage of 
maintainability. It has been estimated that construction of the interface 
module to a given operating system is about 30-50% of the work that would 


have to be undertaken if the complete solution were built from scratch. 


Provisional Recommendations 


1) A study and evaluation should be made of the communications line 


drivers available both from Digital and from groups who have built their 


OWN. 


2) 


3) 


4) 


Bradbury's work on X25 provision seems a good basis for a general 
solution. The problems in coupling this software to a number of 


operating studies should be investigated. 


Bradbury intends to do this for UNIX but there will not be adequate 
manpower for the subsequent development of a fully documented and 
maintained package for general use in the community. The Computer 
Science Department at the University of York has expressed interest 
in this project and has manpower available. It is recommended that 
York at UCL collaborate in the first stage which, if successful, 


would lead to a possible contract for York to develop the UNIX package. 
The linking of Bradbury's X25 software to the other operating systems 
is for further study. Priority should be given to RSX-11-M and a 


suitable group or software house should be sought to undertake this. 


Items (c) to (g) in the list above are for further study. 


R A Rosner 


14 February 1979 
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FIGURE 3 
STRUCTURE OF UCL SOFTWARE 
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FIGuRE 4 


UCL ESTIMATES OF MODULE SIZES 
(EXCLUDING BUFFERS) 


ITEM | SIZE OF CODE (IN 16-BIT worDs) 


FRAME LEVEL + HARDWARE DRIVER 500 
LINK LEVEL 1000 
PACKET LEVEL 2200 
COMSYS - 560 
INTERFACE, WITH OPERATING SYSTEM 500 


4760 
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PDP11 NETWORK USERS MEETING 2ND MEETING 


UNIVERSITY OF LONDON COMPUTER CENTRE 14 MARCH 197° 


Matters Arising from First Meeting 


There are apparently more RT11 installations than indicated in the 
survey taken at the first meeting. (It is extensively used in the London 
medical schools.) 


It was decided to give priority to the following operating systems: 


RSX11-M 
UNIX 
RT11 


Discussion on Working Group Paper 


It was stated that PSS would not support Bisynch framing. 


After a short discussion it was decided to leave LAP in the specification 
for compatibility with EURONET. 


Two new DEC systems may be released soon - RSX11-M3.2, with a few 
additions to present versions, and RSX11-M plus which will need a PDP11/70. 


It was agreed that implementations should go ahead based on the UCL 
scheme. The first implementation should be done with the needs of other 
operating systems in mind so that it can be used as an example. 


An example of the OS interface box now exists at UCL. 


It was stated that as RT1l only consists of two tasks then the PAD 
facility may not be required. ) 


Implementations 


UNIX 


York are interested in doing this implementation and a request is being 
made to the Distributed Computing Panel of the SRC for the necessary funding. 
This project will also probably include high level protocol implementation. 


RSX11-M 


Bristol are interested in this but a decision will have to wait until 
they know if they are going to get suitable hardware. 


Otherwise this is a good candidate for a commercial contract. 


RELL 


Exeter are interested in this - certainly for Q-bus machines. 


RSTS 


Hatfield may be interested. 


The above institutions are going to produce detailed proposals. It was 
agreed to leave the question of communications hardware until later. 


High Level Protocols 


A working group is being set up by the DoI's Data Communications Protocols 
Unit to look into Job Transfer Protocol. The group will concentrate on a spool- 
to-spool protocol and is attempting to define a protocol quickly. This may 
involve a commercial contract to get the required effort. 


A draft document of SG3's Transport Service will be presented at the 
next Networkshop (19 - 20 April). It was agreed that the TS should be part of 
the X-25 implementations mentioned above but that mechanisms should exist for 
bypassing the TS (for X29). 


There was a discussion on whether the HLPs should be implemented at the 
same site as the X25 implementations. The argument for a separate site is that 
it will allow parallel development and thus’ shorten timescales. Interest in 
implementing FTP under UNIX was expressed by Durham and Essex. It may also be 
possible to issue commercial contracts. No decision was made. 


PADS 


It was agreed that there is a general requirement for private PADs. One 
main problem is to decide which terminal protocol(s) to support. The only 
protocol in intensive use presently is the EPSS ITP used in the SRC network. 
However, this protocol is not a serious contender for future standardisation. 


It was agreed that X29 had to be supported in hosts, but for private PADs 
there are at least six contenders. of which XXX is only one. 


A decision was deferred for lack of information and also to wait to see 
what comes out of the projects described above. 


Documentation 
It was stated that the Joint Network Team would distribute the required 
documentation to interested parties. In the meantime, the present Network Unit 


will endeavour to distribute documentation to those requesting it. 


Next Meeting 


The next meeting has been provisionally arranged for 11.00 a.m. on 
Tuesday 3 July at ULCC. 


P S Kummer 


4 April 1979 33 
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Networking with the PRIME computer 


Paul Bryant 
Rutherford Laboratory 
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Networking with the PRIME computer 


With the latest release of the PRIME operating system PRIMOS X25 a la 
Telenet is offered. This provides both HDLC and Binary Synchronous 

link level. Rutherford's interest is to comnect the PRIME to the SRC 
X25 network. Unfortunately, the Telenet Binary Synchronous only retains 
the Binary Synchronous framing around LAP and LAP-B while SRC net is 
based on the IBM held duplex link level. 


Three options are open. Firstly the PRIME code could be modified (a non 
trivial job). Secondly the node could provide HDLC. Thirdly the node 
could provide Binary Synchronous compatible with PRIME. Unfortunately, 
none of these alternatives is trivial and also Rutherford is short of 


stait. 


Even when the link level problem is solved there is no guarantee that the 
cail levels will be compatible but a preliminary examination of the code 


is encouraging. 


At the higher level PRIME provides triple X and PRIMENET. PRIMENET provides 


interactive, file transfers and remote file access between PRIMES. 


Rutherford have implemented FTP-B between their PRIME and GEC computers 

over an asynchronous link. If the connection to SRC net proves possible then 
it 1s intended to implement FTP-B over X25 and possibly the old EPSS ITP 
which SRC uses. Even if the PRIME cannot be connected in the short term it 


is quite likely that FIP-B may be implemented by PRIME and/or SRC. 


Paul Bryant 
ATLAS Computing Division 
Rutherford 
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The connection of a DECnet host to a public network (EPSS) 


Mike Sayers 
Hatfield Polytechnic 
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The Connection of a DECnet Host to a Public Network (EPSS) 


M.D. Sayers 

Head of Software and Services 

The Hatfield Polytechnic Computer Centre 
P.O. Box 109 

Hatfield Herts U.K. 


Abstract 


This paper describes the connection of an ANF1O DECnet network based on the 
DECsystem 10 processors at The Hatfield Polytechnic to the Post Office's 
Experimental Packet Switched Service (EPSS). Some problem areas are 
identified and some suggestions made for improvements. 


In January 1978 the central computing service at Hatfield was provided by 
a DECsystem 1050 serving around 60 simultaneous interactive users. A new 
front end processor (DN87) had recently been added and an ANF1O DECnet 
network was beginning to grow from it, starting with a remote line 
concentrator and RJE station looking like a DEC DN82 but actually being a 
GEC 2050 with Hatfield software in it. 


New computing systems were being planned and it was fairly obvious that a 
Substantial local ANF1O network would be required. In fact, at the time 


of writing this paper, the network is as in figure (1). Not all links are 
yet operational but are hoped to be by the end of 1979. 


DN20 =——_—————  /2 TTY's 
10 9 1 " i 
: | DN2O —S——— 64 TTY's 
v 
mae DCT] 4 TTY's 
CR ,LPT 


8 TTY "s 
—=——_ PTR/PTP 








2020 
(TOPS1@) 


EPSS 
Gateway 





EPSS 


Figure l. The Hatfield Configuration 
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It was clear that access to EPSS and subsequently PSS would be required 
from terminals on any of the processors and that the interconnection of 
processors would be via ANF1O DECnet. It thus seemed reasonable that 
access to EPSS should be via an ANF1LO to EPSS gateway. This should 
provide access to EPSS from any terminal on the ANF1O network and access 
from EPSS to any host on the ANF1O network. 


It is important to note here that, strictly speaking, DECnet applies to 
the PDP-l1l and DECsystem 20 network product which is different from the 
DECsystem lO network. The DECsystem 10 network software is properly 
called ANF1O. This paper deals only with this DECsystem 10 version of 
DECnet. 


The Users View of the Gateway 


Sad The user originating from ANF1O 


To a user whose terminal is connected to some part of the ANF1O 
network the Gateway looks like an ANF1O host. Thus the user may 
get to the Gateway by typing a SET HOST command. After the 
successful execution of this command the user is connected to a 
command decoder in the Gateway. Commands available to him at this 


stage are:- CONNECT address 
DISCONNECT 
STATUS 
ESCAPE new-escape-character 


CONNECT attempts to set up an EPSS call to the given address, 
DISCONNECT clears the currently open call (if any) and 

STATUS types information about the gateway channels which are 
in use. 


Additionally, the Gateway recognises FTP to mean that command level 
replies to the user should be encoded so that they may be recognised 
easily by processes such as FTP. It also ensures greater transparency 
of data than a normal virtual terminal call. 


After SET HOST the user is initially in command mode and the Gateway 
discards all data received except valid commands. Once an EPSS call 
has been successfully opened the Gateway sends all data transparently 
with the exception of any record following the currently active 
escape character. Such records are treated as Gateway commands. The 
escape character may be changed by command. 


For a normal virtual terminal call, data received from an ANF1O 
terminal for output to EPSS is record blocked. This means that data 
characters are accumulated until a character within the pre-defined 
set of allowable break characters is found. The complete record is 
then sent to EPSS. This results in much improved packet filling. 
Invoking the FTP command disables record blocking and all messages 
are sent to EPSS exactly as received from ANFI1O. 
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Record blocking of the type described above imposes no problems 

for our users who wish to access line oriented external systems. 

In practice it has not been found to be a problem with accessing 
other character oriented DECsystem-10's. The only "commonly used 
system program" which cannot easily be driven is DDT - the dynamic 
debugger for assembly language programs and this is fortunately 
hardly ever used on external DECsystem-10's. I think the reason is 
that our users need to access external computers in order to use 
application programs or data bases which are not available on our 
own system. They do not need to go to another DECsystem-10 to play 
with the assembler? 


Jez The user originating from EPSS 


The Gateway supports two protocol process addresses for incoming 
calls, the EPSS character virtual terminal protocol (CHVPT) and a 
"process hook" for file transfer protocols. The Gateway structure 
allows for multiple protocols but others have not really been needed. 
It really is quite surprising how much useful work has been done on 
both incoming and outgoing calls to and from a variety of machines 
just using CHVPT. When one considers that CHVPT contains no terminal 
control facilities at all it is even more surprising. 


For the incoming CHVPT user (calling on process address 300) the 
Gateway provides a transparent data path to the ANF1O host. The 
sequence of events for an incoming call is as follows. When the 
Gateway receives an EPSS Call Originating Packet (COP) it attempts 
to connect to an incoming TTY handler channel on the first ANFI1O host. 
If the connection succeeds a FRP successful response is sent to EPSS 
and the call is fully established. The incoming user is then 
connected, on the ANF1O side of the Gateway, in exactly the same way 
as he would be if he originated at a TTY on the ANFI1O network. Thus 
if, for instance, he wishes to locate himself at a different ANF1O 
host this can easily be done by using the SET HOST command. This is 
processed in the standard ANF1O way by the Gateway. 


As far as ANF1O is concerned the Gateway looks like a single ANF1O 

host node. All outgoing TTY's or TTY handlers look as though they 

are located in the Gateway and all incoming TTY's also appear to be 
located at the Gateway. Thus ANF1O has no knowledge of the network 
on the far side of the Gateway. Similarly, the EPSS network has no 
knowledge of the structure of the ANFLO network. 


The EPSS Service Process 


When the Gateway was first implemented there were very few network terminals 
at Hatfield. Most of the terminals on the DECsystem 1050 (KAI10O) were driven 
as local terminals through a 680I concentrator. These terminals were 
consequently not able to SET HOST to the Gateway. The EPSS service process 
(EPSSER) was developed as a temporary solution to this problem until all 

the terminals became network terminals after the transfer of computing 
facilities to the new DECsystem 1091. EPSSER, however, had developed a 
number of very useful facilities and refused to wither away. 
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EPSSER as originally conceived was to provide a transparent data path 
through the DECsystem-10 to connect local terminals to outgoing channels 
in the Gateway. This was done by connecting to RDX devices in the 
Gateway. Very soon EPSSER developed two additional and extremely useful 
functions; command interpretation and logging. 


It was soon found that the command decoder syntax in the Gateway, which 

was severely limited by memory constraints, was cumbersome for users; 
particularly the address digit string in the CONNECT command. Mnemonic 
addressing is much easier and EPSSER was therefore given the ability to 
intercept CONNECT commands and translate host names into address digit 
strings before passing the command (in abbreviated form) to the Gateway. 
The second function which EPSSER was extended to perform was logging. 

The user was able to instruct EPSSER to open a file on the DECsystem-10 
and to copy all terminal traffic into this file. This was found particularly 
useful by those users whose terminals were VDU's and it worked sufficiently 
well that it was used extensively for file transfer over the network. The 
user just "typed" the file from the remote system and logged it on ours. 
The logging facility also worked in reverse and allowed input to the 
Gateway to come from a file instead of from the users terminal. Using 

this technigue it is possible to run interactive jobs on a remote system 
from JCL files stored on our DECsystem-10. 


Protocol Mapping in the Gateway 


EPSS and ANF1O have a roughly similar protocol level structure as shown in 
figure (2). 





ANF1LO EPSS 

(Device Driver) 

Data Access Protocol (DAP) CHVPT ox FIP 

Network Command Language (NCL) EPSS Call level 

DDCMP (Communications line protocol) © EPSS Link level 
Figure (2) 


Unfortunately the physical link protocol and the logical call protocol 
levels are not as easy to separate in EPSS as in ANF1O and this caused 

the software structure in the Gateway to be more complicated than I would 
have liked. In addition, there was not sufficient correspondence between 
the protocols to allow simple mapping of data below the device level. Data 
had to be unpacked from one family of protocols and then packed up into the 
other. The reasons for this are too complex to be described in detail here 
but the main ones are that the maximum packet sizes are different, the 
device control facilities are different (or non-existent!) and the flow 
control and buffering techniques are different. The data path is shown 
diagrammatically in figure (3). 
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Figure 3. Data path in Gateway 
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The Gateway software is based on the DEC DN80 series node software with 
some internal changes and the addition of command decoder, flow control, 
protocol converted and EPSS driver modules. It is queue driven with 
messages destined for the Gateway being added to a TO EPSS queue from 
which they are removed by the protocol decoder. This extracts data and 
hangs it on the appropriate device/call block queue from where it is 
subsequently removed, repacked and added to the EPSS line output queue 
for transmission. Flow control back pressure is maintained in both 
networks by restrictions on the data queue lengths on the call blocks. 
The number of outstanding messages allowed within the gateway depends on 
the free memory available. 


Features and Problems 


The following discussion is in the nature of a set of notes on features or 
problems in the system. 


The Gateway overheads in terms of processing required per message is 

fairly heavy because of the need to unpack data to the device level in both 
directions. This has not proved to be a problem however, even though our 
Gateway machine is a relatively slow PDP-11/15. The bottleneck in the 
system is the slow end to end data throughput of the EPSS simplified 
protocol which is roughly one quarter of the line speed. The extra delay 
introduced by the Gateway does not noticeably increase the interactive 
terminal response time over that experienced by our ordinary ANF1O terminals. 
Strongly enough response is better for incoming calls than on our locally 
concentrated (6801) terminals. 


Flow control is difficult mainly because data flow control on an EPSS call 
is symmetric but, in ANF1O DAP, Data Requests are only used for output from 
command terminals. There are some internal hacks in the Gateway to produce 
flow control back pressure in the inwards (to DECsystem-10 terminal handler) 
direction. 


It is a problem knowing what to do with EPSS service signals particularly 
how to pass meaningful information back to users. The Gateway provides two 
levels of Command/Service signal information. One gives text messages 
Suitable for interactive users and the other gives encoded messages 
Suitable for communication with processes such as FTP. This information 
level may be changed by command. 


The Gateway allows a maximum of five EPSS calls to be open at any one time 
and it is clearly necessary to have some means of tidying up calls which 
are open but not being used. Calls are therefore timed out and closed if 
no data has passed in either direction for a period greater than the pre- 
set time out period. This is currently set at 5 minutes. Time outs also 
operate at command decoder level to deal with non replies to COP's and 
Similar problems. 


One still partly unresolved problem is caused by there being no EPSS 
facility for the Gateway to tell EPSS at startup to "forget everything you 
think you know about me” and start from scratch. I do not find the 
information which EPSS sends me when I come on-line about calls which it 
thinks I have of any use at all. It just confuses me. I try to remember 
what calls EPSS thinks are open so that when the initialisation dialogue is 
over I can close them but it does not always work. 
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Operational Considerations 


Implementation of the Gateway required no changes to the standard DECsystem-10 
monitor, other than some bug fixes, and the modified DN87 code drives an 
ANF1O remote concentrator node as well as the EPSS network port with 
reasonable reliability. The mean time between failures of the network 
software is 12 hours or greater. 


There are some security questions worth mentioning here. If we allow ANF1O 
terminals to connect directly to the Gateway without being logged in to an 
ANFLO host first then we have no control over access to the EPSS network. 
There are two possible solutions to this problem. Either we require users 
to log in to the Gateway command decoder or we make them log in to a host 
and use EPSSER to access the Gateway. The first seems better because it 
keeps host overheads low but the second.has the advantage that passwords 
and accounting files are normally kept on hosts. 


There are Similar considerations of resource allocation and accounting. 
The next version of the Gateway at Hatfield will in fact provide access 
control and accounting information with files held on local floppy disks. 
These files will be interrogated and/or updated when required by programs 
running on the host. 


Future Developments 


An ANF1LO to PSS Gateway based on the same principles as the one described 
above but containing many improvements including a better command decoder, 
security features, accounting information logging, support for X3/X28/X29 
virtual terminal protocols and support for the "blue book" FTP is now being 
implemented at York. The ANF1O to EPSS Gateway has been providing a service 
to users at Hatfield since the summer of 1978 but it has been equally 

useful as a pilot project for the PSS Gateway. The feasibility has been 
demonstrated and many lessons have been learned which will help to make the 
PSS Gateway a more useful and reliable product. 
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National Exporting Centres Group 


Survey of Communications Monitors 
Introduction 


The National Exporting Centres Group identified the need for a 
development aid for those users implementing corrections to an X-25 
network. The network in question could be a University regional network, 
a rented switch or the Post Office PSS. The development aid should be 
capable of checking out the user's level 2 and level 3 implementation. 


Such a development aid should be capable of running programmes 
supplied by a network management team. The user's implementation could then be 
validated, as much as possible, before attempts were made to connect to the 
network. This should relieve the central network team of much of the 
time-consuming work involved in aiding users at the development phase. 


An adequate development aid would need to be capable of fully 
testing the X-25 line protocols, call set-up procedures etc. and data 
transfers. It should also be capable of simulating a host site to reduce 
the requirement for long interactive test sessions via a telephone circuit. 


A development aid that is powerful enough and flexible enough to 
allow new programmes to be developed as new network facilities emerge 
will not be an inexpensive item. It is unlikely that a user will be able 
to obtain the necessary funding to purchase such a device in order to 
develop his network connection. However the advantages to be gained are 
great. It should be possible, after selection of a suitable instrument, 
to obtain central funding through the Joint Network Team for the purchase 
of a number of instruments for loan to users. 


If a pool of such instruments was to be established then this would 


ensure that all users would be using a well understood common device 
with a common set of programmes. 


The Survey 


Known communications monitors were examined. These were Tektronix 832, 
H.P. 1640A, Halcyon 803A, Datascope 501/502, ERCC PDP-11 Based Systen, 
Tekelec TE92 and Interlekt Intershake. The principle investigation has 
been by means of examining the specifications and demonstrations have been 
arranged for some of the instruments. It is not claimed that all possible 
instruments have been covered. 


The investigation has shown that the instruments fall into three main 
categories. 


1. Low-Medium Speed Monitors ( ¢ 48 kbps) 


(Tektronix 832, HP 1640A, Halcyon 803A) 


ns Low-High Speed Monitors ( > 48 kbps) 


(range of Datascopes) 
3. Low-High Speed Monitors and Simulators 


(ERCC PDP-11 System, Tekelec TE92, Intershake) 
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The Devices in 1. and 2. have sOme simulation facilities but they 
are not considered adequate for the protocol testing that will be required. 
They are basically monitors that are intended for lower level applications. 


A short summary of each instrument, except the Tektronix 832 which 
was not considered worthy of iuclusion, and a comparison table of features 
has been prepared. 


TEKELEC TE92 (Wessen Electronics) 


This instrument comes closest to meeting all the requirements as 
laid out in the table. It is the only commercially available device 
to come close to the requirements. 


It is not clear how easy it will be to create new programs and 
it may be necessary to have a separate 8080 development system or 
cross assembler. The Post Office are concerned about this and how 
easy it will be to make the Transpac programs useable. However if the 
Post Office standardise on this unit then the PSS User Groups may be 
able to ensure availability of programs. 


ERCC PDP-11 based system 


The LSI 11/03 and Floppy version of this monitor does not have 
sufficient performance. A faster PDP-1ll and better disc system would 
perform adequately. The drawbacks then would be lack of part ability 
and lack of system support from the supplier. 


INTERLEKT Intershake 


Limited by a small data buffer and the complexity of operation 
required. It is also bulky in that it comes in three fairly large parts 
(Screen/Monitor, Tape, Console/CPU). 


HALCYON 803A 


This device has a large range of functions which make it a strong’ 
contender for the data monitor function. The drawbacks are complexity 
of operation and speed limitations. It is also not possible to simulate 
hosts and terminals adequately. 


DATASCOPE 501/502 


Although the range of Datascopes have attractive features, they are 
not equipped to offer host or terminal simulation. Program steps are 
limited and program development facilities not readily available. 


HEWLETT PACKARD 1640A 


Speed limitations and lack of programmability make it inadequate. 
It should perform adequately as a medium speed line monitor. 


P, Black 
A.C. Peatfield 43 
ULCC 23.3.79. 


TEKELEC 
TEI2 


REQUIREMENT 





INTERLECT HALCYON DATASCOPE His? ERCC PDP-l11l 
INTERS HAKE 803A 501/502 _ 1640A BASED SYSTEM 
YES >9.6K 
monitor only 
—- extaisliihes a 
GOOD LOCAL STORAGE 4K Bytes + YES YES | ves pes 
ACCESS TO A MASS STORAGE DEVICE YES YES YES baited tied 
| Possible 
ABILITY TO SIMULATE HOST OR TERMINAL YES YES YES Limited Limited 
to develop 
EVENTS OPTIONALLY INTERPRETED IN REALTIME YES YES YES 
SHOULD BE TRANSPORTABLE YES YES YES YES YES 
V-24, v-35 YES YES YES YES YES ES 
User 
| organised 





SPEED RANGE 48 YES 


TRUE FULL DUPLEX YES 








YES 
For Basic YES N/A Questionable 
tLéescs 


SOUND SOFTWARE SUPPORT 








YES with 
special 
tools 


GOOD PROGRAM DEVELOPMENT FACILITIES 


YES 
advantages NO NO NO YES 









YES not 
with Basic 
programs 






ALPHA NUMERIC KEYBOARDS 












not clear 






APPROX. PRICE OF REASONABLE 
CONF IGURAT ION 






HALCYON 


S034 Specifications 


Speeds 


Framing 


Codes 


Protocois 


Interfaces 


interface Test Points 


Interface Display 


External! Input (Transition 
detecior) 


CRT Display 


Display Modes 
Instruction Sei 


Program Entry 


Program Buffer 


60 to S600 bps full duplex. 
50 bps to 19.2K bps half 
duplex. 


56K bps, monitoring only, 
optional. 


Internal speeds: 50, 75, 
110, 134.5, 150, 200, 300, 
6C0, 1200, 1800, 2400, 
4800, 9600, and 19,200 
bps. 


External clock: x1 and x16, 
bps. 


5, 6. 7 or 8-bit with or with- 
out parity bit. 


Synchronous: 1 or 2 sync 
characters (user definable) 
or transparent. 


Asynchronous: 1, 1% or 2 
stop bits. 


ASCli, EBCDIC, Baudot, 
2740/41 Selectric, and 
hex. Others optional. 


Asynchronous and_= syn- 
chronous _ byte-controlled 
(BSC or similar protocols). 
Synchronous _ bit-oriented 
(SDLC, HDLC, and 
ADCCP) optional. 


RS-232-C/V.24 and cur- 


rent loop (20 /40, 20 /60,. 


or 40 /60 mA). 


21 olus ground, metallic on 
front panel. 


21 tristate LEDs: Mark = 
red, Space = green, Inac- 
tive = off. 


Front panel, interface com- 
patible. 


5-inch diagonal, 256 char- 
acters, 32 characters per 
line. 


Time multiplex, line multi- 
plex, and split screen. 


61 macro-instructions, ex- 
pandabie to 99. 


Built-in hexadecimal key- 
board plus 24 special-func- 
tion keys. 


1024 bytes non-volatile 
RAM, expandable to 4096 
bytes. 
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Capture Buffer 


Message Buffer 
Programmable Counters 


Trapping Capability 


Timing Measurements 


Timing Range 
Delay Generation 
Block Check Characters 


ROM Monitoring Programs 


ROM Traffic Messages 
Auxiliary Cutputs 


External Printer Canabiiity 


Operating Environment 


Size 


Weight 
Power 


4096 bytes RAM (2048 
data, 2048 interface iead 
status), expandable to 
8192 bytes. 


512 bytes RAM, including 
BCC. 


10 counters, 
counts each. 


up to 255 


Trap on EIA lead status, 
character pattern, or er- 
rors. 


Turnaround time, elapsed 
time, and EIA lead intervals. 


1 ms to 9.9 min. + 1 ms. 
Selectable in ms or sec. 


VRC/LRC, CRC-16, and . 
CRC-CCITT. Others option- 
al. 


Asynchronous,  Synchro- 
nous, BCP and BOP. 


Fox and 611 bit pattern. 


Composite video and 
asychronous remote RS- 
232-C. 


Asynchronous, ASCII. 


Temperature: O° C to 
eo” iG. 


Humidity: O to GQ%. 
Height: 7 in. (17.78 cm). 
Depth: 19.5 in. (49.5 cm). 


Width, 803A: 13 in. (33 
cm). 


Width, 803A/803A-T: 17 
in. (43.2 cm). 

37 Ibs (16.8 kg). 

100, 115/120, 220, 
230/240 Vac, 50/60 Hz; 
150 VA. 


SO3A-T Specifications 


Tape Configuration 
Tape Head 

Data Density 

Data Capacity 


Data Transfer Rate 
Tape Error Rate 
Weight (803A/803A-T) 


Mini-cassetie. 
Single-channei read / write. 
800 bits per inch. 


60K bytes or Beh bytes 
per side, unformatted (50 
or 80 ft of tape on rrini-cas- 
sette). 


2400 bps. 
<1in 107 bits. 
39 Ibs (17.7 kg). 


HEWLETT PACKARD 


SPECIFICATIONS 1640A 


Note: Specifications describe the instrument's warranted performance. 
Supplemental Characteristics provide information useful for applying 
the instrument by giving non-warranted operating parameters. 


INPUTS 


IMPEDANCE: >30KQ) on all interface connections except ground. 
CONNECTOR: mates with RS-232C (V24) interfaces. 


FORMAT 


FRAMING: 5,6,7 or 8 information bits with or without a parity bit. 
DATA CODES: ASCII, Hex or EBCDIC. Other optional code sets in addition 
to or in lieu of EBCDIC are available. 


DATA MODES 

Asynchronous: 1 or 2 stop bits in addition to information and parity bits. 

Synchronous: 1 or 2 user-entered synchronizing characters. Sync search 
may be initiated on a user-entered character immediately followed by a 
user-entered number of idle characters from O to 99. Idle is defined 
as a steady mark (logic 1's) in all bit positions. 


SPEED 
External Clock (Synchronous) 











HIGH SPEED -MODE* 
Bits Per Second 


NORMAL OPERATION 
Bits Per Second 


CHARACTER 
SIZE INCLUDING 
PARITY (bits) 












*Memory data is not displayed while a run is in progress. High speed 
Switch located on rear of Patch Panel Matrix. 


internal Clock (Asynchronous): 50, 75, 110, 134.5, 150; 200, 300, 400, 600, 
900, 1200, 1800, 2400, 4800, and 9600 bps +1%. Also any external Xl clock 
to a maximum of 9600 bps may be used for asynchronous operation. 


Note: asynchronous operation follows the same speed vs character specification 
as synchronous operation. 


INTERLEKT 


BNE eS sseries 


ENTERSHAERE i 
(BTFA-2-1) Sptiers 


° Option 14C, Rack-Mount Kit 
CAE 22-10 EIA Cable (10 ff) 
e Option 24-5, 56 Kbps High Speed 
Crystal 
e Option 24-(), Standard High Speed 
Crystal, 1 = 19.2, 2= 40.8, 3 = 48.0, 
4= 50.0 and 6 = 64.0 Kbps 
° Option 25, Non-Siandard High Speed 
Crystal, up fo 64 Kbps 
° Option 23-2, Six-Position Crystal 
Oscillator Speed Switch. highspeed 
crystals not included. 
Standard Stored Test PROMS 
Standard Message PROM 
® Option 13-1-2, Special “Stored Test’ 
PROM Set 
° Option 13-2-2, Special “Message” 
PROM 
® Option 13-3-2, ERCDIC 3270 PROM Set 
¢ Option 13-4-2, ASCH] 3270 PROM Set 
° Option 13-5-2, ASCIVEBCDIC 3270 
PROM Set 
e Option 13-6-2, ERCDIC 3270 “G" PROM 
° M548, Mil Sid 188 Modification 
e M550, 1024 Stop Program Cell 
Modificaiion 
e Opfion O07, Loop Interface 
e Option 16, 230V/SOHz Compatibility 
® Option 9O, Upgrade INTERSHAKE II 
Series “A” thru “F’ to Series “H” 
¢ Option 40-1-2, Inter-KEY Keyboard, 
Portable 
¢ Option 40-2-2, Inter-KEY Keyboard, 
Rack-Mount 
Operators Manual 
Operators Guide 
® 37401, Padded Travel Bag for DTM 2-1 
withouf Option 40 
© 37405, Padded Travel Bag for DIM 2-1 
with Option 40 


Peripheral @stiens 


° Option 18-7-2, INTERVIEW I, Portable 
© Option 18-8-2, INTERVIEW I, Rack-Mount 
DTM- 2/INTERVIEW Cable 
e SCNM-1-1, Converter Module INTERVIEW | 
to INTERVIEW 11, SAM- 1-1 


¢ SCM-2-1, Converter Module INTERVIEW | 


fo INTERVIEW II, SAM- 2-1 
Optional Speeds in SCM Positions A, B 
and C 
Ribbon Caotile “TEE Type (6 ff) 
° CRi Option 1, Code Position A, B= BCD, 
REV BCD 
¢ CRT Option 2, Code Position A, B = BCD, 
REV EBCD 
® CRT Option 3, Code Position A, 
B= BAUDOT/ITA No. 2, Field Data 
© CRT Option 4, Code Position A, 
B= BAUDOT/ITA No. 2 REV BCD 
¢ CRT Option 5, Code Position A, 
= IPARS/ITA No. 2 


Nor-Standard Codes in positions A and B 


® 37402, Padded Travel Bag for 
INTERVIEW | or Il 
e {TU-1-2, INTERTAPE, Desk Model 


@ |TU-2-2, INTERTAPE, Portable with 
Rack-Mounft Kit 
Operators Manual 
Power Cord 
DIM-2 INIERTAPE Cable 
e Tape Option 1, speed position 
ABC = 900, 3600, 7200 bps 
© Tape Opticn 2, speed position 
ABC = 1000, 1050, 2000 bps 


‘@ Tape Option 3, speed position 


ABC = 1000, 2000, 3600 bps 
© Tape Option 4, speed position 
ABC = 2000, 3600, 7200 bps 
e Tape Option 5, speed position D = 19.2 
Kdps 
Nor-Standard speeds in position ABC 
Nor-Standard speed in position D 
@ 34129, 30 Additional Data Cariricge 
Labels for ITU-1 
25650, Additional Data Cartridge for ITU 
37407, Padded Trave! Bog for ITU-1 
37406, Padded Travel Bag for ITU-2 
Option 17-1-2, Cassette ikecorder, 
Portable with Rack-Mount Kit 
Option O8-1-2, Printer, Porfanle 
e Option O8-2-2, Printer, Rack-Mount 
Operators Manual 


Accessory Gptions 


e Option 19-2, Auxiliary Interface 
open-end cable 
e Option 20-2, Auxiliary Interface “Y’ 
cable 
e Option 21-2, Spa: re Cable, INTERSHAKE II 
to INTERVIEW 
e Option 22-2, 801C Auxiliary Interface 
“H" cable 
e |FA-2/IFA-3, High Speed Adapters, 
RS-232/V.24 to/from 'WECO 303 
230V/50Hz Version of IFA-2/IFA-3 
© IFA-4/IFAS-1, High Speed Adapters, 
—RS-232/V.24 to/from V.35 
© |FA-4-2/IFA-S-2, 230V/50OHz version of 
IFAr 4-1/1FA- 5-1 
e 34480, Carrying Case for IFA 2/IFA-3 or 
IFAC A/IFAES 
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interface (sertest) 


RS-232/V.24 - 2 connectors aliow the 
INTERSHAKE to be cabled in series with the 
circuit (between the modem and 
terminal/CPU) for the utmost versatility in 
monitoring or emulation. 


imferrace (perahich 


Seven of the RS-232 conirel leads may be 
programmably activated or sensed by tne 
user. TTL logic signals are available as a 
parallel datapoint for iransmii or receive. 


Besvea Late 


15 fixed speeds: 50, 75, 110, 134.5, 150, 
300, 600, 906, 1200, 1800, 2400, 
3600, 4800, 72C0, 9600 bps. Iniarnal 
oscillator: varioble from 45-2400 bys. 
infernal high speed crystal: variable from 
19.2 to 64 Kbps. With external clock: 64 to 
256 Kbps. 


Beate Forma? 


Sync, Async, SDLC. Receiver syncs with O, 
1, 2 syne characters. 


Cxeracter Size 


5, 6, 7 and 8 information bits plus parity 
bit. 


Error Checks 


Real tine calculation for transmit and 
receive: 

Character parity - EVEN, ODD, NONE, 
IRC - 6, 7, 8 bits - EVEN, OFF, 

CRC - SDLC, bisyne and four (4) others - 
normal, inverted. 


Srvor fate flenssrcments 
Up to 999 counts of errors: parity, LRC, 
CRC. 
Base count: 10-108 sequences 
E&ES& Statos Imelizavars 
Twenty-three (23) LED indicators: 4 are tre 
state (2, 3, 15, 17) - red- space green- 
mark/no light-open line. 

wll Evesgsdex/esif Paaiox 
The INTERSHAKE Test Sysig@m can onerate ir 
Full Dupiex or Half Duplex modes. 


Setup 


Orrline monitor setup can be set by panei 
switch or by program instruction. 


INTERLEKT 


Protocols 


The INTERSHAKE Test System is virtually 
compatible with all line protocols. 


Programming 


Program is alphanumeric or HEX using high 
level INTERSHAKE language. 


Program Progress 


Current step executing is displayed during 
progress of program. 


Print Progresm 


Hard copy of programs can be made on 
any ASCII printer, CRT or I/O device that 
has an RS- 232/V.24 Interface. , 


Program Memory 


Each user program instruction function 
placed in program memory is executed in 
one step. A single Function Step is 
equivalent to 5-12 bytes of memory ina 
conventional microprocessor. 


User Program RMAemory 


2048 program steps are accessible at the 
unit. This is an equivalent of 1OK to 24K 
bytes of microprocessor memory. The 
2048 user program steps are availab!e as 
presented below: 


Alterable program memory 


Non-volatile RAM of 1024 steps configured 
in 8 cells of 128 steps each, or 4 cells of 
256 steps each. Immediate access for 
program construction and editing. 
Program memory supported by battery to 
retain program when power is off. 


Stored program memory 

Erasable PROM (EPROM) of 1024 steps 
configured in 8 célls of 128 steps each, or 
4 cells of 256 steps each. Tnese firmware 
programs can be temporarily edited by 
the operator. 


Canned message memory 


Erasable PROM (EPROM) of 1024 
characters configured in eight messages 
of up to 127 characters each. 


‘External Program 
Librery Source 


Store on serial async ASCII device up to 
9600bDps, e.g., Silent 700, ASR 33, etc. 


Program memory from another “like” unit 
Programs can be transferred from one 
INTERSHAKE to another, remotely as well as 
locally. 


Cassette 


Any async ASCIll cassette can store an 
INTERSHAKE program for loter remote or 
local transfer to an INTERSHAKE unit. 


Capture Riemory 


2048 characters of buffer and CRT capture 
for recording test progress, test resulis and 
other data. 


Buffer Capture 


RAM of 1024 characters. Selective 
capture under Program Control. 


ERT Capturc 


CRT capture and display of 1024 
characters is selective and independent 
of the captive memory. 


Buffer Output 


Transmit contents of 1024 character 
capture buffer entirely or selectively under 
program control. Transmils receive data, 
frequency readings, program progress 
markers, counter readings, duration data 
and interface status. 


Translate buffer output 


Translate any or all contents of capture 
buffer to other languages (and HEX) for 
transmission. 


Counting and Timing 


Can measure time, frequency or number 
of events. 

Display is constantly updated and always 
visible. 

Can record up to 1024 readings into 
captive memory uncer program control. 


Data Display 


Large 9-inch, 1024 characier CRT display. 
Displays 1024 characters (16 lines of 64 
characters) or 512 characters (16 lines of 
32 characters). 


Program lustruction 
Functions 


There are over 10C basic “one-step” 
instructions. Instructions are provided for 
all aspects of program path control, sucn 
as Start/Stop, Interim Stop, Restart, Jump, 
Loop and Program Path Change. 
INTERSHAKE is also capable of jumping to 
subroutine and returning to specified 
location. 


Bate inversion 


Single switch selects EIA or MIL 188 type 
operation. 


Data Symchronizaticn 


Forced sync - through program. 
Auto sync - tells the unit what characters 
to sync on. Acis as idle suppress. 


Power 


115V, 60 Hz, 1 Amp. 
230V, 50 Hz (Optional) 


Physical Dimensions 


INTERSHAKE II 
Portable: 
20 inches (50.8 cm) wide, 15.5 inches 
(39.4 cm) deep, 7 inches (17.8 crn) high. 
Rack mounted: 
19 inches (48.2 cm) wide, 13 inches (33.0 
cm) deep, 12-% inches (32.3 cm) high. 
INTERSHAKE II/Inter-KEY: 
Portable: 
20-% inches (52.0 cm) wide, 19-4 inches 
(49.5 cm) deep, 8-% inches (21.0 cm) 
high. 
Rack mounted: 
INTERSHAKE II - 19 inches (48.2 cm) wide, 
18 inches (45.7 cm) deep, 12-% inches 
(32.3 cm) high. 
Inter-KEY - 18-% inches (47.6 cm) wide. 8 
inches (20.3 cm) deep, 3 incnes (7.6 cm) 
high. 


Weight 


INTERSHAKE II 
Portable: 38 pounds (17.3 kg). 
INTERSHAKE 1! /Inter-KEY: 
Portable: 45 pounds (20.4 kg). 
Rack mounted: 
INTERSHAKE II - 28.4 pounds (12.9 kg). 
Inter-KEY keyboard (with cable) - 6 pounds 
(2.7 kg). 


Specifications may change as design Improvements cre introduced. 
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TEKELEC (WESSEX ELECTRONICS) 


Functions 


Connection to the 
network 


Data rate 


Junctions 


Couplers 
Data memory 
Program memory 


Keyboard 


| 


I/O interface 





CRT display 


Software library 


Options 





Power supply 


Dimensions and 
weight 





Analyzer @ Simulator. 


@ Junctions survey and monitoring 


Data rate measurement 
On-line or Off-line. 


From 0 to 72 kbit/s in both directions ot trans 
mission. 


V 24/28, V 35/36 
HDLC, ECMA 24, BSC, Binary. 


RAM : 16 kilobytes ; Mass storage : diskette 
80 kilobytes. 


REPROM : 1G kilobytes ; diskette ; 80 kilobytes 
Extended 20-key hexadecimal keyboard. 


Teleprinter, 50 - 9600 baud. 
High speed paper tape reader 
Video output : 75 2,0, + 4 V, 625-lines 


225 nim diagonal screen 
18-lines of 62-characters, character size 7 x 9. 


Dialogue with the operator (yes, no, value, =) 
permits the TE 92 to be used as an analyzer or 
as a simulator, with procedures HDLC, BSC, for 
a data rate of ..., and with a junction V 24 or..., 
etc... 


Analysis binary, HDLC, BSC, ECMA, CRC 
computation, display of flag number between 
frames, synchronized acquisition “ from “ or 
“up to " in circulating memory or page per page. 
Analytical display (X 25) or. direct display in 
binary, double hexadecimal or ASCII modes. 
Simulation : ETTD type (termina!), ETCD type 


(network), data rate, error injection, junction 
monitoring, caller or X 25-network simulation. 


Extended data memory (+ 16 kilobytes) permits 
continuous diskette recording up to 64 kilobytes. 


Extra diskette (file management, etc...) 


Development of other program library such as : 
“analytical analysis and simulation ™, or other 
procedures (please contact us) 


226 VAC + 10 %, 50 Hz, 300 VA (The instrument 
is powered by a switching power suipply dsveloped 
by TEKELEC).., 


19°’ rack-mounting cabinet, 5 U-Hx 500 mm D, 
equipped with two splash-proof covers. Removable 
keyboard. 


Weight : 15 kg 
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Qualification of terminal. 
Development of terminals 


Checking of data flow in both 
directions of transmission. 


Development of data transmissien 
procedures (line ‘evel) 


Development of data transmission 
protocols (network level) 


Testing terminals {(hardwere end 
software) before connection to thie 
network, 


Testing local or remote modems by 
telelock. 


Testing network using X 25 prutoco! 


Endless recording (circulating me- 


mory) 


Data transmission network survey, 





Dimensions in mm 
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DATASCOPE 


Features and Options 


tSpeed 
Programmable 
Program Entry 
Standard Buffer 
** +Expanded Buffer 
tRerun Program on Buffer Contents 
tProgram Steps 
** +CRC/LRC Calculate 
TInstruction Edit 
Time-correlated FDX display 
Interactive 
Program Load/Unload 
Output Buffer 
2-character Sync 
** +Accessory Adapter 
Codes 
Interface 
Event Mark 
Event Counters 
Timers 
Screen 
Framing 
Display Modes 
Markers 
Idle Suppress 
Data Polarity Control 
Interface Display 
Interface Test Points 
External Event Input 
tVideo Output 
Size 
Weight 
Power 


t New features or enhancements 
* 


** Option at extra charge 


Human language alphabets: XS-3, IPARS, Baudot, 
and BCD Code. 
Other character sets on special order. 


Padded Baudot, IBM 2741, 


High Speed Tape Unit (T-511) 


Remote Connection Units for RS-232, CCITT V.35, 
303 Wideband and telegraph current loop interfaces. 


T-Connector, Model TC-3 





SUMMARY SPECIFICATIONS 


D-501B 


Up to 100 Kbps 

18 Instructions 

Hexadecimal Keyboard 

2,000 characters each side of line 

4,000 characters each side of line 

Standard 

69 | 

Calculate CRC, LRC, & BCC with character delete ability 
Standard 

Standard 

Not Available 

Not Available 

Not Available 

Standard . 

Permits attachment of tape and keyboard accessories 
Hex, ASCII, EBCDIC (2 more optional) 
RS-232* 

Standard 

4 Program Controlled/each counts to 9,999 

4 Program Controlled/each times to 60.000 sec. 
5-inch CRT; 375 characters on 15 lines of 25 each 
5 to 8-bit sync or async and SDLC 

Send, Rev, HDX-2, HDX-4, FDX 

Parity, Carrier, RTS, Event 

Mark, Space or Sync 

Standard 

ALL EIA leads except 1, 7, 9, 10 

ALL EIA leads 

Standard 

Standard 

5-1/4" high x 16” wide x 17” deep 

25 pounds 

120/240 VAC, 50/60 hz, 120 watts 


Speeds above 19.2 KBPS require separate connecting unit. 


OPTIONS AND ACCESSORIES 


D-502B 
Same 
19 Instructions 
Same 
Same 
Same 
Standard 
Same 
Calculate & Generate 
Standard 
Standard 
Standard 
Standard 
300 Characters 
Standard 
Same 
Same 
RS-232* 
Standard 
Same 
Same 
Same 
Same 
Same 
Same 
Same 
Standard 
Same 
Same 
Standard 
Standard 
Same 
Same 
Same 


Video Monitor for Remote Display 
Rack Mounting with Slides, RA-50} 


Freight Shipping Case, TC-501 
ASCII/EBCDIC Keyboard 


Digital Tape Unit, Model T-96 
Program Storage Adapter 


Cassette Recorder 


50 





networkshop 4 


Transport level addressing 


Peter Girard 
Rutherford Laboratory 


_ 


2 wt<.% , = 


< 
. 
a 


he $n ¥ 
A? wel Pelle Al ? 4) 
he jet t 
oF ahi s, eye 
ike ‘ i 
“<. 2D ¢ 


ate gs 
alt 


a igh et or 
a. wn i*% a 
AG ‘a 
ory ad 

~ Ye 


Xe» Se 
SOF Se SF ee wre * 
_—— — ee, ">a 


a 


wt i ah 
’ *! att Y 
: My ye * ; } ‘aed i 
i. 3 7 , mA. re «, Re Lvs ; (ne rt ad a i " a ye ¢ a ball | a cg } 
: 4 ! n a * wf Se P ; ee Aee 7 -) a. y ‘ ‘ Yk ‘in } guy x hel \ . " a 
eT NN ar a 
« ie iA 


— 
as 


Ne oT 4 ‘ 
be Pa ive tht | ‘1 +4 % ie yi . ‘ \ ae 
, 7 7 .4 x | . ‘ ai rs Sk f i 
' | > . 2 » j oe ; f Ay a « y 1 , ' “ Asi f Wi ‘ *% } 7 fi ‘ yy . 
J q ie * | ha . ’ a a cy oy i < - L 7 os, 
LT eG “F " he ert 9 br hile Mey, a hi 


ee 
7 ° 


f rn re 
Pt pet Wt , 
‘ ay ij 


~ 


=. a, 
= 


PS ek 


the —@ oad 


7 x Pe 7" 4 = a « : = - 
eS ee al ~yie¥ ee ee he. 


2 r a 
ee et lg a FS Re 


a3" -» a ae 
“) be 


= 

- 
2 Ss 

- 
_—< 


ca 


.%, < 
: Pca Vane eae RE 0 me Fe 5s Set oS 


4 se =e 


a 


os a « a 29 ss 
— - - 7 
=a =~* La » we . 


“> ~ 


Me 


—*? - 
am Sane o 


, a 
> =e . * 


# & 


hee} 

@ = -< 
ek 
es 
: — 

® 


Cal 
Pe pms oD Sugt Sem 
é 
Re w eens Bo e'- gts ai 
Rae 4 


at 


a, the 


< 


> 
» 
2 


° na ° 


Ng Pe ge BE pe 
ce 8 tak Megttin nn 4 





Cd 
a= 


a4 


PE nots 


e s 
7 * 


Re 


_ « 
ae el ee een 
Se — 
eee. 
2 


‘. > a. 


i. by ™ 
— tee =. es 
pes mre 


L 
? 4 


; ‘ : a , t S at 4 Sas “oWwh ‘ . ! ' § ‘ eat ° tw Mi ; ' wy ‘4 > 
<) 4 > aa: 7 ike \ a) 1% ie 7. ' ‘ : BS mi a r J) \ 4 y ‘ tw A! ro! a " 3 : . 
ey Bal NO Pe i 4 Bs ala Ai? Dy 7 ei eey ie male arty gt ae y Da 
) : , ny ie | AA AHI UR eh y vt | ) rene , oh NAL SS as he aye) sit ‘if; t 
BV eS NOUR AIRS ny, (Pa Ah ah A 
—_— ~ sal ’ = ; P 1 


f 





a 


f< 


4 
"q lon a. . T v@i re tee a ih ff “ oy Sy a ae | 


. Ac eee PY Ale Sa 7. ; 
” il i 4 Ke, att <) rt Cans ‘ . ne Lt, 


a 
- 
- 

a om 


TRANSPORT LEVEL ADDRESSING 


Lg Introduction 


The paper is partly an exposition of the addressing scheme contained in the 
SG3 Transport Service, and partly a discussion of how the basic scheme 


might be put into practice. 


2 PSS Numbering Scheme 


PSS will be linked to other PTT networks, but the PSS numbering scheme 
makes this completely invisible to the customer. Hence the whole collection 
of interlinked PTT networks looks like a single X25 network, from an addressing 


point of view. 


The PSS Numbering Scheme thus belongs essentially to Level 3. The SG3 
addressing proposals belong to Level 4, so there is no conflict between the 


two schemes. 
Need for Level 4 Addressing 


DTE's connected to PSS may be gateways into private networks, or even into 
private multi-network systems within a single organisation. The two optional 
sub-address digits provided by PSS are quite inadequate to cope with the 


addressing problems occuring in such situations, which may well be quite common. 


In any case, a solution is needed where only private networks are being 


interconnected, and PSS sub-address digits do not arise then of course. 


Thus, an addressing scheme is needed capable of coping with any multi- 
network system. Each component network (including PSS if applicable) will 
have its own Level 3 numbering scheme: to link them together we need a 


Level 4 mechanisn. 
4. The Level 4 Addressing Scheme 


To establish a "connection" across a multi~network system, a "connection 
request’ must be issued by the calling end. This must find its way acrss 
any intervening Level 3 networks, by causing a "call" to be set up across 


each network in turn. 


In the SG3 proposal, the connection request takes the form of a Transport 
Service "'CONNECT message" containing two main parameters known as the "called 
address’ and the "calling address". As far as any intervening Level 3 


networks are concerned, the CONNECT message is carried essentially as data: 


51 








in the X25 case it therefore appears in the CUDF, overflowing into subsequent 
packets as necessary. Gateways between Level 3 networks must have at least 

a rudimentary Level 4, so that they can understand and manipulate Level 4 
addresses. A gateway and a transport station are logically identical from 

an addressing point of view, and the term gateway may therefore be conveniently 


used for both. 


Level 4 addressing appears also in ACCEPT, DISCONNECT and RESET messages. 


However, the principles for handling them are the same as in CONNECT messages. 
Bis Naming Authorities and Domains 


A "domain" is the region over which a "naming authority" has jurisdiction, 
and can range from a single computer at one extreme to a collection of 


complete networks at the other. 


The basic assumption is that it is impossible to set up suddenly a single 
centralised naming authority covering all present and future networks. New 
networks or collections of networks are likely to come onto the scene already 


having de facto naming authorities of their own. 


Hence the requirements to be satisfied by a Level 4 addressing scheme are as 
follows. It must allow interworking between different domains, and it must 
facilitate a gradual rationalisation and centralisation of names by making 


it easy for domains to be merged together as necessary. 


6. Single-Network Domains 


The SG3 scheme takes its simplest form when each domain corresponds to one 


Level 3 network. The "called address" and "' 


calling address" each take the 
form of an explicit route specification: a succession of gateway names. 

Each gateway transforms the “called address" by removing its own name from 

the front, and the "calling address" by adding the name of the previous gateway 
to the front. Each name (except the last) has a terminator which the gateway 


concerned must be able to recognise as such. 
Fs Multi--Network Domains 


If the transformation to be applied to the "called address" is looked up 
in a table rather than taking the specific form described above, then the 
gateway code can handle multi-network domains. The transformation for 


Single-network domains becomes a particular case of something more general. 
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The gateway is interested only in the first field of the "called address". 
It applies a transformation to this, but passes the rest of the "called 
address" through transparently. It adds the name of the previous gateway 


to the front of the calling address. 


The diagram illustrates a possible transformation table. The null entries 
imply simple deletion of the field, and correspond to the case of single 
network domains. Transformations may be arbitrarily complex; the only 


requirement is that the next gateway is presented with something that it can 


understand. 
Ss Choice of names 


There are two types of name. The first type is called a "title" and is 
an arbitrarily chosen string of characters. The other type is an explicit 


address, which implies a particular location in the network. 


Titles are convenient from a user's point of view hecause they can be short 
mnemonics, they are invariant to changes of configuration, they allow multi- 
network domains, and they may even offer a choice of routes across such 
domains. On the other hand they must be built into tables and consequently 
require storage space, and effort to keep the tables up to date. In a small 


machine, there may be space to store only the most frequently used titles. 


Explicit addresses are needed as well as titles. These are self--defining 
and require no table space. The most obvious way of assigning explicit 
addresses is to make them equal to Level 3 DTE numbers. They will then be 
numeric (in an X25 context), and valid within a single network. They also 
transform in the standard way: the gateway simply removes them from the 


front of the "called address" for instance. 


The diagram gives some examples of CONNECT parameters in two equivalent 
forms. As previously remarked, the current gateway is interested only in 


the first field: the rest is simply forwarded. 


A simple way of distinguishing between titles and names is to insist on titles 


beginning with an alphabetic character. 
9. Relation to PSS 


In effect, the Post Office has defined only explicit addresses in its own 


domain. There will be no PSS titles. 
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Pit. Conclusion 


The scheme is flexible, and can be used in as simple or as complex a manner 
as circumstances require. In the simplest case, where a straightforward 
DTE is communicating across one network, the Level 4 addressing may reduce 
right down to nothing. It 1s important, however, to realise that this 


Level of addressing is always logically present. 
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TS (or GATEWAY) TABLE 


TITLE | ADDRESS (DTE) | TRANSFORMATION 





ORS.123 
TITLES 
NAMES — 
(EXPLICIT) ADDRESSES 
61.2.0 = 0005.2. 
H4.ITP = 0123.1TP 
ABCD.QWERT12 = 0013 ABCD.QWERT.12 
ELEC = 0001.1TP 
XYZ.QWERT — = 0998.0RS123.QWERT 
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i SYSTEM STRUCTURE 


- Extract from Study Report 
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Et - SYSTEM STRUCTURE 


2 od General Principles 


The Network System will provide: 


- reliable, error free communication between 
programs in network computers; 


—- communication between network terminals and 
programs in network computers and between 
network terminals themselves; 


- common file storage, retrieval and spooling 
services for programs in network computers. 


The implementation minimises the problems of linking 
computers into the system by supporting a vV24 
compatible interface which can be used for simple 
half duplex communication through hardware and soft- 
ware which is standard for the computer involved. 
However the implementation allows for the use of 
more general purpose interfacing facilities and for 
the long term growth of the system in terms of size 
and data transfer capacity. 


The design of the system follows well-established 
data communication techniques adapted and simplified 
for use in a local system. In particular: 


- the system is organised into a series of 
functional layers such that the operation 
of lower level functions are transparent to 
those at higher levels. For example, 
operation of the basic transmission system 
can be changed without affecting either the 
application program interface or the control 
of logical connections. 


- the system is based upon a general purpose 
interconnection facility allowing for 
multiplexing of data streams to and from 
attached computers’ simplified interfaces 
are then provided through this general 
purpose facility. 


The subsections that follow identify the physical 
components which make up the system (2.2 Physical 
Structure), and describe the system organisation 
in terms of the function layers (2.3 Logical 
Structure) . 
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Physical Structure 


The Network System comprises a set of work stations 


interconnected by a Communications Subsystem. The 
initial configuration is shown in Figure 2.2.1. 


A work station may be: 


a server computer which provides one or more 
common services to other work stations on 
the network. It must be able to support a 
number of connections through the network at 
the same time, and these connections may be. 
on behalf of different services within the 
computer. The initial system will have one 
server computer, a CTL Modular 1, providing 
central filing and spooling services and 
communications system support services 


a user computer which requires access to the 
communications subsystem for file transfer 

to and from the file server or to and from 
other user computers, and for terminal access. 
It supports only one connection at a time, 
Operating in half-duplex mode, and can operate 
through a serial line driver which is standard 
for the system involved. 


Teletype - compatible terminals which are 
provided with the facility to set up half- 


duplex connections, normally for terminal 
access to a remote user computer. 


The Communication Subsystem comprises: 


a set of network interface modules (NIMs) 
connected in a ring configuration by serial 
transmission links. Transmission round the 
ring is unidirectional,at up to 50K baud. 
The interface to a network interface module 
will normally be via a V24 interface. 


A network interface module normally comprises 
a communicator which controls transmission and 
a serial node which provides the connection 
between a V24 interface and the basic 
communicator parallel interface. 


a Communications System Manager (CSM) which 


is linked to one network interface module. 
This supports the setting up of connections 
through the system and monitors its operation. 
The CSM is not necessary for the transmission 
of data. 
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The Nelwort System 





Logical Structure 


General principles 


Logically the system is defined in terms of 
applications which communicate through a 
Transport Service. (Figure 2.3.1) 


An application is a program or group of programs 
in a computer work station or the activity of a 
human operator for a terminal work station. 

The Transport Service provides for the exchange 
of messages between applications on the basis 
of logical network identifiers. Control of 
sequences of logically related messages is 
established by setting up virtual calls between 
applications. The application level data in 

a message is transferred unchanged by the 
Transport Service and the size of the message 
is determined by the buffer size agreed by the 
applications. | 


The level of implementation of the Transport 
Service functions depends upon the work station 
involved. In a server computer functions are 
provided through a Transport Station which can 
Support a number of simultaneous virtual calls 
for a number of applications. In a user com- 
puter a specific transport handler is provided 
to support the specific level of function 
required by a. specific application. For a 
Try terminal a minimal level of function 

is provided directly by the network interface 
module. 


Applications in server computers are the File 
Services and the Supervisor Services. The 

File Services provide a set of common data 

storage facilities together with spooling services 
to and from special peripherals. The Super- 
visor services provide for control of system 
operation. 


Applications in user computers are programs 
which write to, or read from the File Server, 
programs for the transfer of data between user 
computers, and programs providing terminal 
services. 
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Network System: Logical Structure 
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Transport Services 


The Transport Services are provided by the 
Communications Subsystem and, where computer work 
stations are concerned, communications software 
in the work station itself. Application programs 
in computer work stations use the Transport 
Services via the set of functions which comprise 
the applications interface; support of teletype 
work stations is compatible with a subset of the 
application interface functions. 


This section is in three parts. First, it 
describes the logical organisation of the Trans- 
port Services; then it defines the functions 
which comprise the application interface; finally 
it describes how the three types of work station 
(server computer, user: computer, and teletype 
terminal) are supported. 


The logical organisation of the Transport Services 


The operation of the Transport Services can be 
defined in terms of three levels of function 
(Figure 2.3.2) 

- the Transport Control level, 

- the Network Control level, 

- the Transmission Service level. 
The Transport Control functions control the setting 


up of virtual calls and the exchange of messages 
between application programs. They use the Network 


Control functions which control the interface to 


the Transmission Services and the transfer between 
network end-points of data messages passed from the 
Transport level. | 


The Transmission Service functions provide for the 
start-up of network end-points and for the reliable 
transmission of data blocks between them. 


The Transport Control and Network Control functions 
are divided between the work station and the serial 
node for computer work stations but are, effectively, 
located in the serial node for teletype work stations. 
The Transmission Service functions are implemented in 
the Table Ronde communicators. 
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Transport Control 


The Transport Control functions provide: 


- virtual call set up and clear down, 


- transfer of data messages on established 
connections, 


- control of message flow on established 
connections. 


Virtual calls. A virtual call establishes a 
logical connection between two work stations. 
The connection is identified at each end by a 
logical channel number assigned by the local 
Transport Control functions. A message on 

an established connection is routed to its 
destination using the network address of the 
destination work station and the logical 
channel number assigned by it to the connection. 


Call set up (Figure 2.3.3) Call set up depends 
upon actions both by the Transport Control 
functions local to work stations involved and 


by functions of the Communications System 
Manager. 


The Communications System Manager is located at 
a fixed network address and provides directory 


services for transport control together with 
logging facilities for calls and for errors. 


Invocation of the LISTEN function by an 
application program results in the assignment 

of a logical channel and the dispatch of a 

CALL REQUEST message to the Communications 
System Manager. The message carries the 

logical network identifier of ‘the source program, 
the logical channel number, and, if specified by 
the application program, the logical network 
identifier with which the connection is expected. 
Invocation of the CONNECT function by an 
application program results in the same actions 
but the CALL REQUEST message will always carry 
the logical network identifier specified in the 
CONNECT function. 


The Communications System Manager responds to a 
CALL REQUEST message with a STATUS message if 
the specified destination is inactive or 
connected, otherwise the request is held until 
it can be matched with another request. When 
two CALL REQUEST's are matched a CALL ACCEPT 
message is returned to source of the first 
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Figure 2.3.3 
Virtual Call Set-up 


message. This message carries the logical 
network identifiers, network addresses and 
logical channel numbers identifying each 
end of the connection. 


When the local Transport Control function 
receives a CALL ACCEPT message it identifies 
the local channel. If the channel is in the 
calling state it is set into the connected 
state, and the remote network address and 
logical channel number are stored with the 
channel control information, a connected 
status is returned to the application | 
program,and the CALL ACCEPT message is sent 
on to the remote address. When the channel 
is in the connected state all messages other 
than DATA, SERVICE, or CLEAR messages are 
rejected to the Communication System Manager. 
Thus the CALL ACCEPT message is exchanged by 
the Transport control functions at the two 
ends of the connection and then returned to 
the Communications System Manager. 


Call clearing (Figure 2.3.4) Invocation of 
the DISCONNECT function by the application 
program at either end of a call results in 
the dispatch of a CALL CLEAR message to the 
remote end of the call and to the 
Communications System Manager, and in the 
release of the logical channel assigned to 
the call. Receipt of a CALL CLEAR message 

by the Transport Control: functions results 

in a status return to the application program, 
the dispatch of the CALL CLEAR message to the 
Communications System Manager, and the release 
of the logical channel assigned to the call. 


Data transfer and flow controli An application 
program requests the sending of a DATA message 
over a connection by invoking the PUT function 
specifying the channel number and the address 
of a buffer containing the message. 


A program allows the receipt of a DATA message 
by specifying a buffer in which to receive it: 
this can be done either through an additional 
parameter on the PUT or by an invocation of the 
GET function specifying the channel number and 
the input buffer address. 
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A DATA message header contains a sequence 
number and a receive buffer count which 
specifies the number of input buffers 
assigned at the sending end since the last 
message sent by it. If there is no DATA 
message to be sent or the sending of a DATA 
message is not allowed, a SERVICE message 
will be sent to convey the buffer receive 
count. 


Invalid messages. A message can be invalid 
because it has an invalid code, because it 

has a code which is invalid for the state of 
the channel, because it is out of order etc. 
Invalid messages are sent to the Communications 
System Manager if necessary with explanations 
information appended. On a established call 
some invalid messages may cause the call to be 
disconnected. 


Network Control 


The Network control functions provide: 


- message fragmentation (for transmission) 
and reassembly, 


- packet formatting, and packet transfer 
and reception across the Transmission 
Service interface, 


- Transmission Service interface control. 


Message fragmentation and reassembly. The 
unit of transfer through the Transmission 


Service is a packet comprising header 

and data. Where a message is longer than can 
be transferred in a single packet the message 
is broken down into message fragments which 
are transferred in a sequence of packets and 
reassembled at the destination. 


The packet size is a system parameter and can 
be adjusted to fit the traffic pattern. Only 
DATA messages can be greater than the maximum 
data space size for a packet and will be 
fragmented if necessary. Reassembly is 
controlled by the message sequence number on 
the connection and the packet number within 
the message. 
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Packet formatting, transfer and reception. 


A packet header comprises the destination 

or source network address, the packet length, 
the destination logical channel number, and 
the message and packet sequence numbers. 
Control of thé transfer takes place via the 
control interface of the Table Ronde 
communicator. 


Transmission Service interface control. 
Facilities are provided across the interface 
to the Table Ronde communicator 

- to reset the equipment, 


- to logically disconnect it from line 
and connect it to line, 


- to run loopback tests, 
- to run diagnostic transmissions. 


These facilities can be invoked at node start 
up or when an error has been detected. 


Transmission Services. 


The Transmission Service functions are provided 
by a set of Table Ronde communicators linked in 
a ring configuration. The communicator control 
functions provide for: . 


- network start up, close down and recovery 
from transient faults, 


- communicator start up, close down and 
restart, 


- for the reliable transmission of packets 
between communicators (on the basis of a 
network address). 


The internal operation of the communicator and 
of the Transmission Service are described more 
fully in section 3.2.1 and the associated 
annexes. 
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Work Station Support 


All work stations interface to the Transmission 
services via a serial node supporting a V24 
compatible interface. The Transport Control 
and Network Control functions are then divided 
between the work station and the serial node. 
The actual division of functions depends upon 
the work station involved. A work station and 
network interface module are assumed to be 
located together so that no error control 
procedures are used on the link but there is a 
flow control procedure. 


Server Computer Support 


A server computer can support a number of 
virtual calls at the same time. The link to 
the serial node is full duplex and packets 
carrying messages or message fragments for 
different calls are multiplexed over the link 
in both directions. 


The Transport Control functions are located in 
the work station. The major part of the Net- 
work Control functions are in the work station 
and interact with the serial node to control 
the communicator interface by the exchange of 


control and information transfer packets. 


User Computer Support 


A user computer can only support a single 
virtual call at one time and the link to the 
serial node is half duplex. ) 


Transport control is shared between station 
and node. Call set up is carried out through 
the action of the serial node in response to 
the transmission to it of a CONNECT message. 
Call clear down is similarly an action of the 
serial node in response to a DISCONNECT message 
from the User computer or to a CLEAR message 
from remote end of the connection. 


Network control is similarly shared. The work 
station controls message fragmentation and 
reassembly but the serial node is responsible 
for setting the network address. The work 
station and serial node interact by the exchange 
of control and information transfer packets. 
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Teletype terminal support 


For Teletype work stations all control functions 
are provided within the serial node. A single 
virtual call is suppotted and the link to the 
work station is half duplex. For input from the 
terminal the serial node assembles the input 
character string into a message and adds the 
appropriate header depending upon the state 

of the virtual call. For output the node strips 
off header information and outputs any character 
string that the message contains. 


At initialisation time the user declares a 

message termination character and an escape 
character. The message termination character 

causes the serial node to turn round the link. 
(that is, to be prepared to receive a message after 
the message has been sent). The escape character 
allows the input of a standard control character 

to clear a call. 


Thus, following initialisation of the node, the 
terminal user inputs a string which is taken as 
the logical network identifier of the call 
destination. If the call request is successful 

a prompt is displayed and the terminal user can 
then input a character string to send, or put the 
terminal in the state to receive from the called 
party by typing the termination character. The 
call is terminated by typing the escape character 
followed by a code character: typing escape 
followed by the message terminator returns the 
system to the normal input state. 
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2 THE TABLE RONDE SYSTEM 
- From Minicomputer Forum, Online 1976 


This paper describes a prototype implementation. 
The system proposed for the network is a 
production version operating at up to 50K bit/sec 


and with an improved interface and diagnostics. 


Current prices are: JOOOOFF per communicator 
4500FF per serial node 


for quantities of 10 or more 
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Using the Cambridge data ring 


M. A. Johnson 


Introduction 


The data ring at Cambridge iS now in use, and a variety of 
machines are connected to it. The aims of the current software 
work on the ring are twofold: 


- to provide a convenient means of transferring information 
between the machines, several of which cannot otherwise 
communicate with anything else. 

- to research into the types of protocols most appropriate on the 
ring, and the development of distributed operating systems. 


Basic block protocol 


The packet of data sent around the ring is very small (16 
useful bits). Most ring transfers are done in terms of a larger 
unit -—- the 'basic block’. This has a header packet, a routing 
‘packet, 1-1024 data packets, and a checksum packet. The header 
packet contains a distinctive bit pattern, some type bits, and a 
count. The route packet consists of some reserved flag bits, and 
a port number, which is used to route the data to the correct 
place in the target machine. The checksum packet is there 
partially for error detection, but itsS main purpose is to protect 
against framing errors caused by erroneous detection of header 
packets. It is intended that basic blocks should be handled at a 
very low level —- e.g. microprogram or dedicated microprocessor, 
but this is not essential. A policy decision has been made that 
all errors noted at this level (block timeouts, unknown port 
number, genuine ring errors ete.) should be ignored. Thus the 
interface presented to the next level of software is one in which 
blocks either arrive correctly or fail to arrive at all. 
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Higher level protocols 


Higher level protocols are built on top of the basic block 
protocol. Wherever possible, use iS made of 'stateless' 
protocols, i.e. those in which state information is preserved at 
one end of the communication only, and there is no long lasting 
connection. Such protocols are generally designed in such a 
manner that any error which occurs can be dealt with by a simple 
retry. The file server protocol consists entirely of transactions 
of this type. A typical transaction, read, is done as follows. 
The client sends a basic block containing the message "send me X 
words of file F on port P, and acknowledge on port A". The client 
merely checks that the acknowledgement is OK and that the correct 
amount of material arrives. If anything goes wrong (e.g. no reply 
after a timeout interval) the client simply tries again (changing 
the port number P in case the original request is eventually 
serviced). With care, many services can be deSigned in this 
manner. 


For some purposes, state preserving protocols are essential. 
At present one of these is defined, the byte stream protocol. It 
provides a pair of synchronised byte streams with flow control. 
Most of the facilities of the Post Office Packet Switching Study 
Group 3 Transport Service proposal are provided, but it is simple 
enough to implement on a Z80 microprocessor. (Most of the 
restrictions are in the area of non-local addressing; extension 
to provide these facilities would not be very difficult). 


A brief summary of ring research and development at Cambridge. 


The CAP computer (a machine built for research into 
protection in operating systems) provides various services to mini 
computers. File transfers are possible using a simple file 
transfer protocol built on top of the byte stream protocol. 
Terminal access via the ring should be available soon. 


An LSI/4 mini computer with 160 Mb of dise storage will be 
used as a file server. The design is complete, and implementation 
1s in progress. 


It is planned to make a major change to the CAP's operating 


system, to enable it to use the file server instead of its own 
disc, doing swapping via the ring. 
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A Z80 based microprocessor system has been produced. These 
can a) interface the ring to devices such as terminals and 
printers, and b) provide simple services such as name lookup. 
Fach is usually dedicated to a single purpose; 4 are currently 
built and working, ultimately 6-10 will be in use. 


A high speed DMA interface for mini computers, based on the 
8X300 microprocessor, has been designed and the prototype is being 
constructed. It will handle the basic block protocol, and has 
facilities for rebootstrapping and debugging its host. Six LSI/4 
mini computers have been bought to interface in this manner, and 
it is intended that they will have the ring as their only 
peripheral. The development of techniques for’ uSing them 
effectively is a research topic. 


The Computing Service intend to interface their mainframe 
(IBM 370/165) via a PDP11 to the ring. This gives potential 
access to wider area networks. 


Request 


Dato. 
(oa dake pert ) 


Reply 
(on reply port) 


Typical fileserver transaction 


(read) 
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The Kent implementation of the Cambridge ring 


Matt Lee 
Kent 
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University of Kent at Canterbury 
Computing Laboratory 


Ring Project 


Summary of the Report given at Networkshop4 


Basic Brief 


a) Build an exact copy of the Cambridge Ring and connect 5 


POP-11"s to ita 


a) Assembling a current set of documentation. At the time the 
documentation was needed, changes were being made to the Work 
Station and Monitor Station designs. This meant rough diagrams, 


intended for guidance only, were available. 


b) Making design decisions in the light of the available 
documentation. It was decided that the most recent designs of 
Repeater, Work Station and Monitor Station should be adopted 


because: 


i) connection to future hardware (e.g. the LSI chips) would 


be straightforward. 


Tn 


ii) construction of parts of the Repeaters and Work Stations 
could be started, and this work would fill the time until the new 


designs were fully documented. 


Experiences of Building the Ring 


a) Onee designs were fixed for the Repeater and Work Station 
construction was straightforward, as was construction of the Ring 


Power Supply. 


b) Monitor Station construction was again sty michitorverd. but 
both the Cambridge prototype and the Kent prototype were completed 
at about the same time. This meant commissioning the Monitor 
Station was slowed slightly by intermittent calls to Cambridge to 


confirm and/or accept modifications. 


ec) A constructional error delayed the Work Station wire- 


wrapping by three days. - 


a) A record of the timescales for the construction of the 
Repeaters, Work Stations and Monitor Station is shown on the copy of 


Slide 1 at the end of this report. 
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Costs 


a) The costs of parts of the Ring and of an example 10 node 
Ring are shown on copies of slides at the end of this report. They 


are 


Slide Title 
2 Repeater 
3 Work Station 
4 Monitor Station 
5 PDP-11 Interface 
5 10 Node Ring. 


b) Notes. 


i) The costs shown are based on the prices of components 


between July 1978 and May 1979. 


ii) The labour cost is based on a rate of two pounds per 


hour. 


iii) The time spent by the author on the project is not 


shown. 
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Administering the use of networks 


John Rice 
Liverpool 
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ADMINISTERING THE USE OF NETWORKS 


Dr. John D. Rice 
Computer Laboratory, University of Liverpool 


Introduction 


This paper examines the problems with which Computer Centre management 
will be faced when PSS connections are available from the university campus. 
Freely available use of PSS facilities could lead to considerable uncontrolled 
expenditure and therefore it will be necessary to preserve solvency by prevent- 
ing undesirable incoming and outgoing PSS access and use whilst ensuring that 
the level of service provision is sufficient to meet the needs of genuine users. 


PSS Connection and the Campus 


For the purpose of the ensuing discussion it will be assumed that the 
typical university campus Gontains a campus network which is linked to a 
regional network, which itself is linked to the PSS network. For our’ 
purposes the regional network may be considered as a part of the PSS network (as 
in most cases it will be). 


We may therefore identify the following methods of connection from the 
campus to PSS (see Figure 1):- 


A. Packet Mode 


Lie Campus network connection via a Gateway 
Zs Mainframe connection 
3 Character terminals connected through a local concentrator pro- 


viding PAD facilities. 


B. Character Mode 


Ls Character terminals directly connected to a PSS PAD 


Qe Character terminals connected to a PSS PAD via the PSTN 


R8 


Mainframe 


A2 


Figure 1: 


Terminal 
Concentrator 


CAMPUS A3 
NETWORK 


/_cateway 


PSS Connections from the Campus 
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Bl 


B2 


Areas for Control 


PSS tariffs cover three major areas, namely Access, Usage and Facilities. 
Since charges may be accumulated under each of these headings it is necessary 
to consider the control of each area separately. 


An associated problem is caused by the need to bill directly the consumer 
of network services from the campus. The implications of this will also be 
considered. 


Controls in the Absence of a Transport Station 
pa 


Access Control 


It is quite likely that connections both to and from equipment on the 
campus will use X3, X28, X29 facilities built directly on top of the X25 
connection. The implications of such a mode of connection need to be con- 
sidered. (Typically this would apply to connections Bl and B2 (See Figure 
1) and also possibly A2 and A3). 


Firstly it will be necessary to ensure that there is no abuse of the 
calling capability. That is, it must be possible to prevent users from 
making large numbers of unsuccessful call connect attempts as each such attempt 
is chargeable. | 


Secondly it may be necessary to restrict ‘access: to certain facilities. An 
example of such a facility is the placing of international calls. Here a useful 
spin-off of a reverse charging policy may be utilised, namely that international 
reverse charging is not permitted. This method of control may easily be imple- 
mented in a terminal concentrator providing local PAD capability A3(See Figure 
1). The implication of a reverse charging policy of course is that each callable 
national site should be prepared to accept reverse charges and consequently have 
a means for subsequently billing them to the caller. An alternative method of 
reducing iccess is by the use of the closed user group, of which more later. For 
character mode terminal access only by the PSTN use of multiple Network User 
Identifiers (for each university department?) provides a simple method of billing 
(P.O. diicci to Department) ,if not control. 


Finaiiy, the Post Office could be prevailed upon to provide a subscription 
time option with international calls barred. 


Unfortunately, what most universities are likely to require is a selective 
barring, and in the Triple —- X environment it seems that multiple addresses with 
most barrwi-would then be the only solution. 


The foregoing has referred to outgoing access from the campus to PSS. It 
is clearly recessary for those sites wishing to provide remote access to their 
mainframe via PSS to provide adequate facilities for billing the use of local 
host facilities and PSS reverse charges (if accepted). It might appear at first 
that with reverse charge acceptance one simply accepts a call, allowing access to a 
terminal channel, and then bills the user who subsequently “logs-in" to the host. 
However, this would not provide for the recovery of costs if the user fails in 
his "log-in" attempt. In some implementations it may be possible to provide 
checks of the calling party on the mainframe's FEP which is answering calls, but 
this may lead, in the general case, to unacceptable localised mass storage require- 
ments. 


Tratfic Control 


Ideally one would like to control the cost of the traffic which campus 
users can generate over PSS. The worst-case situation is when such access 
is via the PSTN, since any controls in this case must lie within PSS itself. 
Since call charges (if the subscription-time option is exercised) are notified 
in terms of duration and volume it is unlikely that direct cost controls would 
be provided. 


If the Post Office were to provide an option to limit the segment count 
and call duration on a per-call basis this might go part of the way to solv- 
ing the problem. However, since the equipment accessing PSS over the PSTN 
may be a computer, which could re-connect calls quickly, the need arises for 
an additional limit on call frequency. Alternatively, a cumulative segment 
count limit (over a month, say) could be a useful subscription-time facility. 


Control with a Transport Station 


It is a debatable point as to whether or not the collection of call stat- 
istics is a proper function of the transport service or of a superior session 
control service. For the purpose of the following discussion it will be 
assumed that such a service is provided at the transport level. 


Access 


The subject of Transport Service addressing is still under discussion. 
However, irrespective of the conclusions reached, the following possible 
implementation features should be considered: 


(a) the use of Titles as the only permitted TS addresses; 
this would limit access thmugh the TS to a set of addresses 
contained in local tables 


(b) blocking on certain destination addresses; 
e.g. international addresses | 


(é) blocking access from certain local network calling addresses 


Ne 


Whilst primarily in this section we are concerned with functions of the gate- 
way between the campus network and PSS, the discussion is in terms of TS imple- 
mentation, since this is of more general interest. 


In the particular context of the gateway, which we may assume to be on a 
host, the file store requirement of the above features is not a problem. 


Usage 


Usage must be monitored in terms of volume and duration (preferably com- 
pounded as cost) and the ability at liaison set up to specify volume and 
duration limits (with suitable defaults) would be useful, as would notification 
of liaison cost-on disconnection. When limits were reached the TS would be 
required to automatically disconnect the call. 


Facilities 
A user access profile held at the gateway and related to campus users by 


their local account codes could incorporate not only access and usage control 
bounds but also permitted facilities (such as reverse charging). 
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Bil Ling 


Users,particularly computers which access PSS sites from the campus 
network, will require charge details on a per call basis. The simplest TS 
implementation with one call per network per liaison (i.e. no multiplexing) 
could utilise the PSS call statistics facility to provide such data. An 
implication of a multiplexing TS would be the necessity of incorporating such 
statistics collection within the TS. One advantage of TS intelligence should 
be the notification of actual costs for all calls. 


The question of the level of detail to be provided at the end of an account- 
ing period seems open. The provision by the P.O. of accounts information 
itemised by call is only likely to be of value if it is accessible in machine- 
readable form. 

Standardisation 

It will greatly simplify matters for the local network user if the campus 

network implements the same call charging algorithm as PSS. 


Charging 


The spectre of charging for computing within the university community has 
recently re-appeared and future campus networks need to be constructed with this 


in mind. "Presumably each local net has effective techniques for recording 
charges and collecting fees from local hosts" {1] ‘ Is that true of all UK 
university campus networks? Should it be? 


Certainly if apportionment of PSS charges between local campus users is 
required, in accordance with the assumption: ''Presumably each local net autho- 
rity will collect both local and internet fees from local users, exchanging accu- 
mulated internal charges with other nets periodically" [1] , then certain 
gateway features will need to be present, namely machine access to both local 
and PSS acccunts on a call by call basis. 


Closed User Groups 
To end on a practical note, if we cannot exercise total control over our: 
users use of PSS, we need to implement the least restrictive effective limited 


control. 


One way of exercising such control is via the closed user group facility. 
Three such groups may be identified: 


(a) Regional CUG 


this would permit incoming access from all PSS subscribers and 
outgoing access to the National Centres CUG for each member 


(b) National Centres CUG 


incoming access would be permitted from the members of all 
regional CUGs. 


(c) Special-Arrangement CUGs 


these would be established on an ad-hoc (charged!) basis to allow speci- 
fic inter-regional access e.g. a Database CUG could be set up. 


The application of the CUG facility to the university environment is recommended 
for serious consideration. 


Conclusions 


The subscription-time facilities of PSS require close examination to 
determine those most useful for the control of PSS use within the university 
community. A recommended set could be defined by the Joint Network Team. 


Further, a TS implementation guide is urgently required which seriously 
addresses the subject of user control. 


Without such controls the cost to the universities in PSS charges result- 
ing from undesirable access (intentional or wMintentional ) could adversely 
affect policy on the use of PSS by genuine university users. 
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SUMMARY AND CONCLUDING REMARKS 
Roland Rosner 


This Networkshop has left the very definite impression that more and more 
people in the community are now concerned with network implementation. The 
discussions have therefore had much more of a practical flavour than at 
previous workshops where the emphasis was on pure protocol definitions as 


Paper exercises. 


An important corollary to this change of balance is the much wider base of 


experts that has now come into being in the community. 


We have learnt a lot about the Transport Service and it is particularly 
pleasing to note how much effort has gone into its definition by members of 
Post Office Study Group 3. The Protocols Unit was responsible for organising 
the meeting which gave SG3 its new lease of life. Perhaps one of the more 
stimulating discussions was on the tariff implications of X25 from which it 
emerged just how vulnerable standards are to crude economics. Structuring a 
tariff in a particular way can lead to tariff-cracking by technical means 


which could effectively destroy the standard. 


Work has at last begun on the job transfer protocol problem and there are 
grounds for hoping that a definition may be ready by the end of the year. 
Precedent suggests that, no matter how many willing experts make part-time 
contributions, protocol definitions are only produced when there is at least 
one individual who can devote himself to the work for a substantial fraction 


of his time and coordinate all the input generated by the others. 


More and more sites are now thinking about plans for local area communications. 
The ideal is a high bandwidth system with widespread access points, cheap 
interfaces, high reliability and the ability to carry traffic from synchronous 
and asynchronous devices. The Cambridge ring is a candidate for use in some 
places; in other environments, centralised X25 switches are under consideration. 
There is a risk that, in the absence of supported products from manufacturers, 
Many centres will undertake their own developments. The JNT will be recommending 
to the Computer Board that funds be made available for the exploitation of the 
different techniques as pilot projects at a very limited number of sites. 

There will also be negotiations with manufacturers to stimulate the early 


availability of catalogue items. The excellent presentations on the ring 


showed some of the difficulties to be overcome in developing fully engineered 
products out of research projects. | 
Development work on devices such as concentrators, RJE stations and gateways 
will be coordinated to ensure the emergence of widely applicable products and 
to reduce the risk of duplication. Projects carried out as contracts under 
the auspices of the JNT will follow the already established pattern which 
seems to be operating quite successfully. This entails the formation for 
each such project of a steering group comprising appropriate experts from 
sites in the community acting as consultants to the JNT. Such a group then 
contributes to a tight functional specification of the work to be carried 


out and holds periodic meetings to monitor progress. 


The JNT would welcome information on any current projects which are felt to 


have wider than purely local applicability. 


The discussions have shown that the next Networkshop(to be held at Kent from 
the evening of Tuesday 18 September until Friday 21 September 1979) should 


include coverage of: 


PSS X25 Level 3 

The final version of the Transport Service Definition 
The interim report on the Job Transfer Protocol 
Gateways 

Communications Hardware 


How to use old kit in a modern networking environment. 


18 May 1979 
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Papers not included 


The following papers were received too late for inclusion in the proceedings: 
Report on the GEC 4000 range activities for networking - John Horton 
(GEC) 


Report on the Honeywell Multics activities for networking - Kit Powell 
(Avon) 


General description of the Post Office Study Group 3 proposals for a 
transport service - Peter Linington (Protocols Unit) 


Implications of Post Office tariffs on transport service - Peter Linington 
(Protocols Unit) 


Job transfer - what facilities are needed? - Jeremy Brandon (Queen Mary 
College) 


The Structure of a job transfer protocol - Andrew Chandler (CADC) 


The South West region's requirements for a campus switch - Howard Davies 
(Exeter) 


Progress report on the Cambridge ring - Andy Hopper (Cambridge) 
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This report is one of a series published by the Department of Computer 
Science at the University of York. The purpose of publication is to 
present our experience and ideas to inform colleagues and friends ina 
way which strikes a balance between ad hoc memoranda and formally 
refereed papers. It is intended that appropriate reports shall be 
revised in the light of comments received and offered for publication 
in the technical literature. 


The numbering of reports in the series is continuous, but the report 
covers are colour coded according to the technical content. (Yellow 
for teaching and research, blue for the Computing Service.) 
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